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In this Issue 




We didn't plan it that way, but two groups of articles in this issue deal with 
the design of software to make user interaction with computers simpler, more 
consistent, more intuitive, more standard, more foolproof. One group of 
articles describes a standard graphical user interface and the other describes 
an environment that provides a consistent user interface for software develop- 
ment tools. Since we didn't do anything special to get these two packages 
into the same issue, their simultaneous appearance — close on the heels of 
the HP NewWave Office — is simply further evidence of the attention that 
user friendliness is receiving in the R&D community. 



The graphical user interface is called OSF/Motif. It's the first product of the Open Software 
Foundation, an international organization created by leading computer companies to promote 
open software standards — standards that make it easier for users to mix and match applications 
and computers from different suppliers. Based on technology from Hewlett-Packard and Digital 
Equipment Corporation, OSF/Motif provides consistent behavior between personal computers 
and engineering workstations and an enhanced 3D appearance that makes buttons look as if 
they've been pressed when the user selects them. HP's implementation of the OSF/Motif graphical 
user interface is described in the three articles on pages 6 to 35. The first article discusses HP 
OSF/Motif concepts and external behavior. The other two articles discuss the two main HP 
OSF/Motif components: the HP OSF/Motif window manager and the HP OSF/Motif widgets. The 
widget library is a programmer's toolkit that makes it easy to develop applications that have the 
OSF/Motif graphical user interface. 

The software development environment is called the HP SoftBench environment. It provides 
software developers with a unified, consistent interface to the computer-aided software engineering 
(CASE) tools they most often need. Tools included in the HP SoftBench product are a program 
editor, a static analyzer, a program debugger, a program builder, and electronic mail. Using an 
HP SoftBench component called the HP Encapsulator, other tools can be added to the environment 
and HP SoftBench tools can be replaced with other tools. Provided that they meet certain minimum 
requirements, encapsulated tools don't have to be modified at all. The HP SoftBench environment 
is designed to support development teams in distributed computing environments. It can be 
customized to conform to local organizational, team, and personal processes, and any tool can 
execute on any computer in the user's network. The HP SoftBench user interface follows the 
OSF/Motif appearance and behavior. (Because of the small size of the screen images shown in 
the articles, the 3D appearance isn't apparent there, but you can see it on the cover.) The HP 
SoftBench tool integration architecture is described in the article on page 36. The HP SoftBench 
CASE tools are explained in the article on page 48, and the HP Encapsulator is the subject of 
the article on page 59. 
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"Hyphenated techniques" is a name chemists use to refer to certain combinations of analytical 
techniques. One of these is liquid chromatography mass spectrometry, or LC MS. The constituents 
of an unknown sample mixture are separated by a liquid chromatograph, and a mass spectrometer 
is used to identify and measure the concentration of each constituent. It's not entirely straightfor- 
ward. An interface is needed between the two instruments to control the flow rate and remove 
the solvent that carries the unknown through the chromatograph. While several interface tech- 
niques have been tried, none has been completely satisfactory. However, the relatively new 
particle beam interface looks good. It is applicable to a wide range of compounds and produces 
spectra that have high information content. The article on page 69 introduces us to particle beam 
LC/MS. describes the design of HP's particle beam interface, and presents performance data for 
the HP system. 

Equipment for testing integrated circuits at the wafer stage — before the individual chips are 
separated — typically consists of an automatic test system, a prober, and a probe card. For testing 
high-pin-count or high-speed devices, conventional probe card designs just don't work reliably in 
factory conditions. The paper on page 77 presents the results of research aimed at developing 
an alternative. HP's proprietary membrane probe technology replaces the conventional probe 
card and its needle probes with a thin, flexible dielectric film supporting a set of microstrip 
transmission lines that have microcontacts at their ends. Complex, high-density contact patterns 
are easily formed photolithographically. Contact resistance was found to remain low and stable 
for up to a million touchdowns with only a simple cleaning every 20,000 cycles. The paper presents 
performance results from alpha-site tests. 

R.P. Dolan 
Editor 



Cover 

An HP SoftBench window environment, showing the OSF/Motif 3D appearance. 



Whal's Ahead 

The August issue will contain about one third hardware design and two thirds software design. 
The hardware consists of the HP 8130A 300-MHz, variable-transition-time pulse generator and 
the HP 81 31 A 500-MHz pulse generator. The software is HP's implementation of the Manufacturing 
Automation Protocol, MAP 3.0. 
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Making Computer Behavior 
Consistent: The OSF/Motif Graphical 
User Interface 

Window-oriented user interfaces provide knowledge 
workers with powerful tools to control their computer 
environments and increase productivity. The OSF/Motif 
graphical user interface provides standards and tools to 
ensure consistency in the appearance and behavior of 
applications running in the X Window System. 

by Axel O. Deininger and Charles V. Fernandez 



■ MACINE THE PROBLEMS IT WOULD CAUSE the driv- 
I ing public if there were no standards lor the location of 
I the brake and gas pedals on an automobile. Fortunately, 
the auto industry has standards for the location of certain 
items that are critical for the operation of an automobile. 
In the computer industry, standardization and consistent 
behavior of the user interface for computer applications is 
not yet a reality. User interfaces defining how people and 
computer programs communicate with each other still dif- 
fer from one application to another. 

Inconsistent user interfaces make it much more difficult 
for users to learn and operate different applications. This 
problem is accentuated in multitasking operating systems 
such as HP-UX. whose appeal includes the ability to run 
several programs at once. The cost of such inconsistency 
is more than just a little frustration for computer users. 
Inconsistency causes users to be hesitant or to avoid using 
or purchasing new computer applications, thereby causing 
lost revenues to application vendors, and possibly lost pro- 
ductivity because the new applications might enable tasks 
to be done more quickly and efficiently. 

Hewlett-Packard's efforts in developing and promoting 
a cooperative computing environment are based on an in- 
terest in industry standards that support a consistent user 
interface. HP's adoption of the UNIX* operating system as 
the basis for the HP-UX operating system and early support 
for industry standards such as the X Consortium and the 
Open Software Foundation (OSF), are examples of HP's 



interest in this area. The X Window System'" from the 
Massachusetts Institute of Technology has been available 
on HP-UX systems since 1988, and the OSF/Motif graphical 
user interface, completed for OSF in 1989. Is now available 
on HP-UX 7.0. The OSF/Motif user environment is based 
on HP's graphical user interface CXI (common X interface). 
See the box on page 8 for more about OSF. 

This article describes some of the concepts and external 
features provided by the OSF/Motif graphical user inter- 
face. The articles on pages 12 and 26 describe the two main 
components of the OSF/Motif user interface: the OSF/Motif 
widgets and the OSF/Motif window manager. 

Concepts for Consistent Behavior 

The following concepts are essential for designing a con- 
sistent user interface: 

■ An object-action design model that is universally applied 
and simple to understand 

■ Direct manipulation of objects with immediate and con- 
sistent visual cues for feedback 

■ Tools that are consistent enough to ease the learning 
burden of novice users, yet flexible enough to allow ex- 
perienced users to take shortcuts. 

The object-action selection model means that the user 
first selects an object and then selects an action to perform 
on that object. Standard controls such as menus and push- 

The X W,ndow System is a trademark ol the Massachusetts InsHule of Technology 
UNIX Is a registered trademark of AT&T in the U S A and in other countries 
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buttons represent the selections. The objects typically rep- 
resent a real-life metaphor that the user is familiar with. 
For instance, in the HP NewWave Office. 1 the objects in- 
clude file cabinets, folders, and documents. Consistent be- 
havior implies that the set of controls and objects will 
always operate in the same way. 

Direct manipulation with visual feedback means that the 
user is provided with a response that somehow represents 
the action taken, and it is done in real time. For example, 
when a button on the display is selected, the visual feed- 
back might be that the button appears to be pressed in. 
Real-time feedback implies that the manipulation of objects 
on the display is synchronized with the motions of the 
device (mouse and buttons) being used to perform the man- 
ipulation. For example, the events on the display should 
not lag behind the motion of the mouse. 

Consistent behavior does not eliminate individuality, nor 
does it imply rigid conformity. Much flexibility exists 
within consistent behavior for application developers to 
present their applications in the best possible light. Novice 
users typically make a menu selection by displaying the 
menu, reading the selections, and then clicking the mouse 
over the item they want. Experienced users make selections 
using a quicker method, such as entering a one-letter 
mnemonic or bypassing some menu levels. The specific 
controls such as pushbuttons and scroll bars do not repre- 
sent a finite set, but rather a basic, core set that is expected 



to evolve as technology changes and users gain more experi- 
ence. 

Tools for Knowledge Workers 

To be productive using a computer, knowledge workers 
must have tools that enable them to communicate with and 
economize control over the programs running on the com- 
puter. The two most common tools for this purpose are the 
traditional typewriter-style keyboard and a pointing de- 
vice — usually a mouse. 

Standard Mouse Techniques. Traditionally, control over 
the computer has relied on the user's ability to type. This 
is being rapidly replaced by the use of pointing devices 
such as the mouse. A mouse enables the user to control 
most operations using three actions: 

■ Pointing. Positioning the mouse pointer over an object. 
This signals a possible interest in that object. 

■ Clicking. Pressing and releasing a mouse button selects 
the object. Double-clicking, or clicking a mouse button 
twice in rapid succession, selects an object and then 
performs the designated default action on the object. 

■ Dragging. Pressing the mouse button and moving the 
pointer enables a user to move objects, select a range of 
objects, or browse a menu (depending on the context of 
the situation). 

The shape of the mouse pointer indicates the current 
operations taking place in the user interface environment. 
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Many pointer shapes are possible. Each shape is visually 
descriptive and provides an important visual cue about the 
operational state of the interface. Fig. 1 illustrates some 
common pointer shapes. 

By using the modifier keys Shift and CTRL in combination 
with the mouse, the user can select a single choice, several 
choices, a contiguous range of choices, or a noncontiguous 
range of choices. 

Keyboards. A typewriter-style keyboard may be the tradi- 
tional tool for computer users, but graphical user interface 
environments like OSF/Motif do not require users to be 



keyboard experts or to learn the arcane syntax of traditional 
command-line interfaces. 

Although the tools of a graphical user interface such as 
the mouse are easier to use, keyboards remain the most 
efficient tool in some cases, particularly for text entry. Also, 
a number of keyboard alternatives exist. Arrow keys can 
emulate mouse movement and can be just as fast as a mouse 
when only a few objects are on the screen, or when the 
user's hands are already on the keyboard. Single-letter 
mnemonics and keyboard accelerators for commonly used 
commands also show that the keyboard is still a useful 



OSF/Motif 



The Open Software Foundation (OSF) is a group of Ihe leading 
companies in the computer industry organized to promote open 
software standards. The foundation is incorporated as a non- 
profit, industry-supported research and development organiza- 
tion that has the responsibility to provide software that makes it 
easier for users to mix and match computers and applications 
from different suppliers by addressing the following needs. 

■ Portability. The ability to use application software on computers 
from multiple vendors. 

■ Interoperability. The ability to have compulers from different 
vendors work together 

■ Scalability. The ability to use Ihe same software environment 
on many classes of computers, trom personal computers to 
supercomputers. 

In response to OSF's request for user interface technology, 39 
companies including HP presented their visions of the future of 
computing. HP's vision of a common X interface (CXI) that united 
the behavior of Presentation Manager* m the personal computer 
world with the power of workstations in the UNIX-system world 
was chosen as Ihe basis upon which to build an OSF user inter- 
face slandard. 

OSF awarded HP a contracl to develop and document a CXI- 
based user interface. This became the OSF's first product, the 
OSF/Motif user interface. Like CXI, the OSF/Motif user interface 
is based on a three-dimensional appearance and the behavior 
of Presenlalion Manager, which is a standard graphical user 

'Presentation Manager is a product of Microsott Corporation 



interface of the personal computer world. The OSF/Motif product 
includes a style guide that defines a common user interface 
behavior consistent with Presentation Manager, a window man- 
ager to conlrol graphical objects on the display screen, a software 
toolkit of widgels and intrinsics with which to build applications, 
and a user interface language lo speed application prototyping 
The article on page 1 2 describes the OSF/Motif window manager, 
and the article on page 26 describes the OSF/Motif widgets. 

The OSF/Motif user interface is Ihe mosl visible piece of what 
will become a complete OSF/Motif user environmenl. II thus plays 
a rnaior role in making the applications that run on UNIX-system- 
based systems more user friendly. The OSF/Motif environmenl 
enables users to operate their computers with graphical controls 
like pushbuttons, windows, and menus. Where once users had 
lo memorize dozens of obscure commands and type flawlessly, 
now they need only point with a mouse and click a button, 

Fig 1 shows the interactions between the window manager 
and a client application. The X Window System is an accepted 
standard in the UNIX-system world and is the platform for Ihe 
OSF/Motif widgets and intrinsics. The OSF/Molif window manager 
provides the Presentation Manager appearance and behavior 
characteristics for applications. Because OSF/Molif follows a 
technology slandard, users need no longer ponder issues of 
hardware and software compatibility. Because OSF/Motif follows 
a behavior standard, users need not learn multiple command 
sets to control applications. Once they understand direcf manipu- 
lation, they can control any program. 
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interface tool. 

Special Tools. The keyboard and mouse are by no means 
the only tools available. Consistent behavior supports the 
use of many tools for just about all occasions. Hewlett-Pack- 
ard's Human Interface Link (HP-HIL) provides many inter- 
face tools for computer users. Which tool is used depends 
on Ihe application and the user. For example, a mouse 
might not be appropriate as a pointing device in all cases. 
If the application is a computer-aided design (CAD) appli- 
cation, perhaps a graphics tablet or light pen might be a 
better choice. If the situation is such that a minimum of 
desk space exists, perhaps a track ball would be a better 
choice as a pointing device than a free-roaming mouse. 

Windows 

Windows are the means by which users view the world 
inside their computers. Each window displays a separate 
view. In a multitasking environment, a user can have many 
windows operating at the same time. With networked X 
Window System technology, each window can show activ- 
ity on a different computer, even a computer thousands of 
miles away. Fig. 2 illustrates a typical window environ- 
ment. 

Like most work areas, a window environment is not im- 
mune to disarray. Indeed, with remarkably little effort, the 
workplace (display) can easily become cluttered to the 
point of distraction. Windows typically overlap like pieces 
of paper on a desktop. New windows open on top of the 
stack, partially obscuring older windows lower in the stack. 

There are a number of ways to organize the work area. 
Controls are present on the window frames for the conve- 
nience of mouse users. Fig. 3 shows Ihe layout of a typical 
window in the OSF/Motif window manager environment. 
Windows can be moved out of the way by dragging the 
title bar. The window frame itself is not just a border: when 



grabbed by the mouse, the border stretches or shrinks to 
resize the window. 

When moving or shrinking a window is not enough to 
get it out of the way. the window can be turned into a 
graphical icon by clicking on the minimize button in the 
window frame. The icon saves space on the screen without 
halting the application running in the window. This is 
analogous to a person putting a clock in a desk drawer — the 
clock still works, it's just out of the way. 

To give a window undivided attention, the user can click 
on the maximize button in the window frame. This will 
enlarge a window to its maximum size and will often cause 
it to cover the entire screen. This is a useful feature for 
complex CAD design. 

Menus 

Consistent behavior provides a number of ways for users 
to control the windows in their work areas. The idea is 
that no one way will be correct for everyone, so by building 
flexibility into Ihe environment, users can pick a way to 
manage windows thai best fits the situation. To help pro- 
vide this flexibility, every window has a window menu. 
Users can display a window menu either by clicking the 
left mouse button with Ihe pointer positioned over Ihe 
window menu icon for lhat window, or by pressing Shift 
and ESC simultaneously. If the window menu is hidden, 
it can be revealed with the click of a mouse button. 

The window menu shows all of Ihe window management 
commands available for a window. Fig. 4 shows the con- 
tents of the default menu for the OSF/Motif window man- 
ager. This menu duplicates Ihe commands embedded in 
the window frame and may provide different commands 
as well. To initiate an action from the menu, Ihe user po- 
sitions the mouse pointer over the desired selection and 
clicks the left mouse button. For keyboard-oriented selec- 
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tion, the user can type a one-character mnemonic. 
Mnemonics are the underlined characters in a menu entry 
(see Fig. 4). Typing the keyboard accelerator (shown after 
the menu entry) will perform the command without dis- 
playing the menu first. Keyboard accelerators are the fastest 
way to invoke frequently used commands. For example, 
pressing the keys Alt and f9 simultaneously will minimize 
a window. Users can customize keyboard accelerators to 
suit their personal needs. 

Controlling Applications in the Window 

Of greatest interest to users is not the window, but the 
application running in the window. Fig. 5 shows a typical 
application's main window. The bulk of the space in the 
window (known as the client area) is reserved for display- 
ing the application. This can be text for a word processor 
or a schematic for a CAD package. 

Commands used to control the application are tucked 
away in the menu bar at the top of the window. The menu 
bar lists the titles of available menus. To display a menu, 
the user positions the pointer over the menu title and clicks 
the mouse button, or uses one of the keyboard techniques. 
Selecting a command from a menu bar menu is Ihe same 
process as selecting a menu item from the window menu 
described earlier. The menu bar menus can contain both 
commands, which are actions that occur immediately, and 
settings, which are states of being (such as double-spaced 
text) that are not actions themselves but that affect sub- 
sequent actions such as printing. 

Standard Menus fur Standard Actions. Standard menus 
are recommended for standard actions to ensure consistent 
behavior among applications. The titles of the standard 



Fig. 6. A sample dialog box. 

menus for an application are listed in the menu bar. Three 
of the standard menus include: 

a File. Contains file actions like opening, creating, saving, 
and printing a file. 

■ Edit. Contains edit actions like undoing, cutting, copy- 
ing, pasting, and clearing sections of a file. 

■ Help. Contains helpful information like context sensitive 
instructions, information on the use of keys, index list- 
ings of help topics, and information on how to use the 
help function. 

Pop-up Menus. Check Boxes, and Pushbuttons. The menu 
bar presents an effective compromise between providing 
an efficient storehouse for a large number of actions and 
presenting visual cues so users can readily see what choices 
are available. 

Pop-up menus are a good choice for applications that 
want to place the most commonly used actions under Ihe 
fingertips of mouse users. They are particularly effective 
in text and graphics editors. Users can select a range of 
text and press the second mouse button to pop up the 
menu. There is no need to travel with the mouse pointer 
to the menu bar. Pop-up menus are very fast when used 
with the mouse drag technique. 

Applications that want to make certain action choices 
visible all the time can use pushbuttons to place them in 
control panels. Radio buttons and check boxes are used in 
the same way for settings. All of these controls are modeled 
after real-life objects. Pushbuttons are found on many elec- 
trical appliances. The radio buttons stem from a car stereo, 
hence their use for mutually exclusive settings (a radio can 
be tuned to only one station at a time). Check boxes appear 
on many paper forms such as job applications. 
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Dialog Boxes. Dialog boxes are so named because they en- 
able users to carry on a dialog with an application. Fig. 6 
shows an example of a dialog box associated with a 
hypothetical copy command. The sample dialog box con- 
tains a text entry box for entering the name of a style sheet, 
a set of radio buttons for indicating mutually exclusive 
units of measure, check buttons indicating settings for type 
style, option menus provding a limited choice of margin 
sizes, and a row of pushbuttons indicating what action 
should be taken. 

Conclusion 

Window-oriented graphical user interfaces offer an op- 
portunity to make the computer as pervasive an appliance 



as the automobile. But, if they are truly going to do so there 
must be standards for consistent behavior. A behavior stan- 
dard has advantages for both computer users and computer 
vendors. Users are finding programs easier to learn and 
use. The market for standards-conformant applications is 
growing. Vendors are finding they can produce more appli- 
cations while concentrating their product efforts on de- 
veloping performance and features rather then developing 
user interfaces. 
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The HP OSF/Motif Window Manager 

The HP OSF/Motif window manager, which is built on top 
of the X Window System, is a window management interface 
that provides a 3D enhanced Presentation Manager 
appearance and behavior using HP OSF/Motif widgets. 

by Brock C. Krizan and Keith M. Taylor 



THE X WINDOW SYSTEM, Version 11 (also known 
as X or XI 1 1 1,2 was developed as a platform on which 
a variety of user interfaces can be implemented. The 
particulars of a user interface are determined by the X 
clients that run on the system. X clients are programs that 
use X to display information and receive input. The HP 
OSF/Motif Window Manager (mwm) is one such client. 

Fig. 1 shows the relationship between the X Window 
System and clients. The OSF/Motif window manager mwm 
implements an interface that allows user and client ma- 
nipulation of windows. Mwm dictates through its window 
management interface a particular user interface behavior. 
The principal objects that are manipulated using the win- 
dow manager are the client windows placed directly on 
the background, or root, window of the screen. Windows 
within these top-level client windows are managed by 
clients and are not directly manipulated by the window 
manager. Users are provided with ways to move and resize 
windows, to direct all keyboard input to a particular win- 
dow, and to install color maps' for a window. 

X. as it comes from the Massachusetts Institute of Tech- 
nology (MIT), provides mechanisms for supporting clients 
that implement a variety of window management user in- 
terfaces. A sample window manager, uwm, is distributed 
by MIT. Several window managers have been implemented 
al companies and universities to meet the needs of a par- 
ticular application environment, to emulate some non-X 
Window System user interface, to provide the latest new 
and improved window management interface, orto provide 



personal customizations of uwm. Window managers are one 
of the most common types of X clients. 

With so many window managers available, implement- 
ing another window manager would seem to be a waste of 
time. However, the window manager is an essential and 
highly visible part of any window system user interface, 
and (he usability of a system can be significantly affected 
by the window manager. Prior to the availability of mwm's 
predecessor, the HP window manager, or hpwm. HP custom- 
ers who had access to X used the sample window manager 
uwm or, less frequently, window managers available in the 
public domain. HP wanted lo give users an interface that 
was visually refined, consistent, easy to learn, and based 
on industry standards. 

Hpwm supports industry standards in appearance and be- 
havior as well as X standards for client interoperability. 
The appearance and behavior of hpwm is based on Presen- 
tation Manager, which also defines the window manage- 
ment appearance and behavior for HP's NewWave Office. 
Users already familiar with the Presentation Manager stan- 
dtrd from the personal computer environment now find 
their skills useful on an HP-UX workstation. The three-di- 
mensional visuals of hpwm represent a refinement, not a 
change, from Presentation Manager standard appearance. 

In 1988. the Open Software Foundation (OSF) accepted 
HP's proposal that hpwm be adopted as the basis for the 
OSF/Motif window manager. The commitment to Presenta- 
tion Manager as an industry-standard user interface was 
key in OSF's decision. OSF/Motif encompasses several 



12 HEWLETT- PACKARD JOURNAL JUNE 1990 

©Copr. 1949-1998 Hewlett-Packard Co. 




^^^^ ^^^^ ^J^^ 



Oiner Workstations 
or 

Host Computers 



I 



Network 




Workstation 



Fig. 1. The X client-server model In this model the X server 
is near the user and controls the display and manages the 
input devices. The clients in this model are the applications 
that talk to the server using the X protocol, such as mwm, 
XLOAD, and XCLOCK The X protocol allows the clients and 
server to run either on the same machine or on different 
machines connected by a network (a) X client-server ar- 
chitecture on stand-alone workstation (b) X client-server re- 
lationships in a distributed environment 



technologies built on top of the X Window System, and 
the new OSF/Motif window manager is only one piece of 
the OSF/Motif environment. 

Window Manager Characteristics 

The basic set of functions that a window manager pro- 
vides is relatively constant in any window system. On the 
other hand, the appearance and behavior vary greatly from 
one window manager to another. Many of the characteris- 
tics of mwm were leveraged from hpwm. This allowed us to 
meet an aggressive schedule and still satisfy the function- 
ality and quality goals for mwm. 

Common Appearance and Behavior 

Like hpwm, the appearance and behavior of mwm are heav- 
ily influenced by Presentation Manager. Indeed, the default 
behavior of mwm, as well as that of the OSF/Motif widgets, 
is as close to Presentation Manager as is practical. A key 
benefit of this is that users can easily move between systems 
running MS/DOS* or OS/2 and systems running the HP-UX 
operating system and X Windows. Nevertheless, some dif- 
ferences were admitted into the design of mwm to satisfy 
the variety of HP-UX users and to use the power of engineer- 
ing workstations. This has led to a window manager with 
a high degree of configurability and an enhanced appear- 
ance over Presentation Manager. 

Key behavioral aspects of Presentation Manager and the 
OSF/Motif environment include the direct manipulation 
of objects and an object-action paradigm for user interac- 
tion. Direct manipulation involves using the keyboard and' 

MS-DOS ts a U.S registered trademark ot Microsoft Corporation 
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or mouse to do window management functions directly, 
such as moving and resizing a window. A user does not 
enter a command such as move -w mywindow 10 y = 100. but 
rather drags the window using the mouse to the new posi- 
tion. With the object-action paradigm, the user selects an 
object and (hen performs some action on the object. 

3D Appearance 

One deviation from strict adherence to the Presentation 
Manager standard is in the appearance of the user interface 
components. The three-dimensional visual style developed 
for earlier HP products was accepted by OSF as part of the 
OSF/Motif standard. 3D components appear in both the 
window manager and the OSF/Motif widgets. Use of 3D 
components strengthens the direct manipulation paradigm 
by providing visual objects that react naturally to user ac- 
tions (e.g., buttons appear to go in when pressed), 

Mwm uses the OSF/Motif widgets to provide visual and 
operational compatibility with other clients that use the 
OSF/Motif widgets. All parts of rnwm are displayed with 
the 3D visual style. This includes the window manager 
frame, icons, and menus. A key factor that influenced mwm's 
use of the 3D visual style was the prevalence of window 
manager components on the screen. The challenge was to 
provide a 3D appearance but not to distract from or limit 
the client user interface. Mwm is designed to be frugal with 
its use of screen space, subtle in its use of 3D indications, 
and restrained in its use of color. Fig, 2 shows a client 
window and the various window manager components. 

Configurable Appearance and Behavior 

Although mwm implements the Presentation Manager be- 
havior with a 3D visual style, configurability was consid- 
ered a desirable departure from a strict Presentation Man- 
ager model. In some cases configurability applies to aspects 
of the user interface that are not constrained by the standard 
appearance and behavior. The colors of components and 
the fonts that are used fall into this area. Configurability 
can also alter the standard appearance and behavior in 
fundamental ways. Since il is almost impossible to provide 
a single, fixed user interface acceptable for all users, con- 
figurability is highly desirable. 

Configurability of mwm is provided in a way that does 
not burden users who are satisfied with the window man- 
ager's standard appearance and behavior. Mwm provides 
the standard appearance and behavior as a default and 
allows for user customization. Configuration is only neces- 
sary if there are specialized requirements. In addition, mwm 
provides a function that resets all customized mwm settings 
to default values to give the user a known starting place 
from which to work. 

It is anticipated that only a small group of system ad- 
ministrators will want to customize mwm. To make their 
job easier, mwm uses the same resource names for specifying 
configuration values for colors and fonts as are used for 
OSF/Motif widgets. The result is that configuring mwm is 
similar to configuring any client built using OSF/Motif 
widgets. 

ICCC Compliance 

Compliance with the standard Inter-Client Communica- 



tion Conventions (ICCC) developed by the X Consortium 
is a requirement for any X client. These conventions are 
intended to facilitate interoperability of X clients. Clients 
that follow the conventions can coexist on the same screen 
and not interfere with each other's behavior. This applies 
particularly to the communication between clients and 
window managers. The ICCC is the basis for the program- 
matic interface to X window managers (see the box on page 
23). 

Mwm implements the ICCC standard in a way that is com- 
patible with the standard OSF/Motif behavior. This allows 
a user to run a client even though il was developed without 
specific knowledge of mwm. 

Mouse and Keyboard Interfaces 

Window managers are often implemented with a reliance 
on the mouse for user interaction and the keyboard is ig- 
nored. The OSF/Motif behavior specifies a functional 
equivalence between mouse and keyboard interaction. 

Mwm is fully functional when it is run on systems that 
do not have a mouse input device. Not only does the stan- 
dard OSF/Motif behavior have keyboard support, but mwm 
supports features beyond the OSF/Motif standard. For 
example, keyboard and mouse interaction can be mixed 
together, even while doing a particular action such as mov- 
ing a window. 

OSF/Motif Window Manager Operation 

Mwm has two basic phases of operation: start-up and event 
processing. At start-up. mwm asserts itself as the window 
manager for a particular screen, processes configuration 
information, and takes care of currently displayed client 
windows (see Fig. 3), Event processing is the steady-state 
phase of operation. Like most X clients, mwm is event driv- 
en — that is, it waits for some type of X event, processes 
the event, and then waits again. In the event-processing 
phase, all mwm actions are the direct result of some event. 

Start-up 

When mwm first starts up it must indicate to the X server 
that it wants to be the window manager. The X server has 
no notion of a special window manager client, but there 
are some X facilities that are necessary for window manage- 
ment that cannot be accessed by more than one X client. 
By asserting control of these facilities, mwm effectively locks 
out other window manager clients (conversely, mwm is 
locked out if another window manager is already running). 

The primary facility over which mwm gains control is the 
facility for redirecting several types of X requests from 
other clients (see Fig. 4). Usually a client makes a request 
to the X server to do a function and that function is done 
immediately by the server. With a redirected request, the 
function is not handled by the X server, but is passed to 
the redirecting client (i.e.. the window manager). The win- 
dow manager decides how to handle the redirected request 
and then makes the request, sometimes changing the re- 
quest to be compatible with its window management 
policies. 

The types of X requests that are redirected by mwm in- 



14 HEWLETT-PACKARD JOURNAL JUNE 1990 



© Copr. 1949-1998 Hewlett-Packard Co. 



elude: 

■ Window configuration (moving and resizing) 

■ Window stacking (who's on top of whom) 

■ Window mapping (display of a window on the screen). 
These requests are redirected only when they apply to 

top-level client windows, which are windows displayed 
directly on the background or root window of the display. 
Using its ability to redirect X requests, mwm can control 
when, where, and how client windows are displayed. 

Once mwm has asserted itself as the window manager, it 
can then configure itself and prepare to do event process- 
ing. In general mwm has its configuration specified through 
resource files like other X clients (see Fig. 5). These resource 
files contain user-specific configurations, client-specific 
configurations, and screen-specific configurations. 

Resources that are specific to fonts, colors, and bit maps 
are defined and referenced in general-purpose resource 
files. However, not all configuration resources can be con- 
veniently specified in a general-purpose file. The mwm re- 
source description file (usually called .mwmrc) contains 
descriptions of resources that are difficult to specify in the 
general-purpose resource files. Mwm menus, mouse seman- 
tics, and keyboard semantics are described in the mwm re- 
source description file and referenced in other resource 
files. 

The last thing that mwm does during its start-up phase is 
adopt client windows that are currently being displayed. 
Mwm assumes control over the placement of client windows 
on the screen. In the usual case where mwm is the first 
client to be started there will be no clients to adopt. 
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Fig. 3. OSF/Motif Window Manager start-up process 




(a) (b) 

Fig. 4. Event redirection (a) If no window manager is running 
(no redirection), the client's window mapping is done im- 
mediately, (b) When mwm is running, the server redirects the 
client's map window request to mwm Mwm adds its window 
border before asking the server to complete the window map- 
ping. 

Processing 

After mwm completes start-up it goes into a loop waiting 
for and processing events. Events are messages from the X 
server that are generated as the result of some user or client 
action. 

When a top-level client window is to be displayed on 
the screen, the window manager receives a map request 
event. In processing the request, the window manager re- 
trieves client-specified and user-specified configuration in- 
formation to place the client window on the screen. The 
client window is reparented to a window manager frame 
window. In effect, the client window is placed inside a 
window manager frame window. This is the mechanism 
that allows mwm to give all clients a common top-level 
window border. In the frame window, around the outside 
of the client window, are placed the window manager di- 
rect manipulation components shown in Fig. 2. Once the 
client window is dressed up in its window frame, it is 
placed on the screen. 

User interaction with the window manager results in 
mouse (button and motion) events and keyboard (key) 
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Fig. 5. Resource files used by mwm 
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events. When a user interacts with a direct manipulation 
window manager component, a stream of events is gener- 
ated. Mwm associates the events with a particular user inter- 
face component and invokes the associated function. Im- 
mediate visual feedback of the user's interaction maintains 
the appearance and behavior of (he direct manipulation 
interface. 

Users can configure window manager actions to be in- 
voked by particular key or button events. This interface to 
the window manager is in addition to the standard interface 
which is based on direct manipulation of window manager 
components. Mwm arranges with the X server to grab button 
and key events that invoke window manager functions. 
This grab mechanism allows the window manager to get 
the events even while another X client window is receiving 
keyboard input. 

Termination of mwm is triggered when a window manager 
function invoked by a user or by an event indicates that 
the X server has been shut down. When mwm is terminated, 
the window frames that belong to mwm are destroyed. Nor- 
mally, all the child windows of a window that is being 
destroyed are also destroyed. However, since mwm repar- 
ents client windows to their window frames at start-up, 
the desirable behavior is for the client windows to be re- 
parented back to the background (root) window so that the 
clients can continue to run. To accomplish this, mwm uses 
the XI 1 save set mechanism to cause client windows to be 
reparented back to the root window when mwm terminates. 
By placing all client windows that have been reparented 
to window frames into its save set, the windows are automat- 
ically reparented back to the root window by the X server 
when mwm terminates. 

Restart 

The restart function is invoked when a user wants to 
reconfigure mwm. Restart is necessary because some re- 
sources are only read by mwm in its start-up phase. Any 
aspect of the mwm configuration can be changed at any time 
using the restart function. The window manager restart 
function effectively terminates the current instantiation of 
mwm and starts a new one. This function is special in that 
it causes mwm to make a complete pass through both of its 
operational phases. The event that invokes the restart func- 
tion is processed in the steady-state event processing phase. 
Restart execution begins with the termination of mwm and 
completes when mwm starts up again. 

OSF/Motif Window Manager 
Implementation 

Like the features and characteristics of mwm. most of the 
code and design for mwm were leveraged from the HP win- 
dow manager. The period when hpwm was designed and 
implemented was one of rapid change for X and for HP's 
use of X. This had to be taken into account in formulating 
an implementation strategy for mwm. For example: 

■ Hpwm was implemented at the same time that there were 
new developments in user interface technologies and 
components. However, to minimize risk, stable technol- 
ogies were used in favor of the newer ones. 

■ The user interface components that hpwm used were often 



first-generation products. Therefore, visual and perfor- 
mance tuning of these components could not be relied 
upon. 

■ Prototype versions of hpwm were required to refine the 
3D visual style, to support usability testing, and to sup- 
port prototype application environments. 

■ Standards that hpwm used were under development in 
parallel with the implementation of hpwm. 

The implementation strategy used for hpwm involved sub- 
stantial prototyping and design, followed by bottom-up 
reimplementation. Prototyping and design accounted for 
more than half of the engineering and calendar time spent 
on implementing hpwm. Development of a prototype de- 
layed dependencies on user interface components and 
facilities. The prototype was used to identify visual and 
performance problem areas requiring design refinements. 
Design decisions were substantiated or changed based on 
experience with the prototype. 

After the prototype and hpwm. mwm can be viewed as the 
third pass on the window manager. The experiences gained 
from the earlier efforts were used during the definition and 
implementation of mwm. Also, the use of the hpwm engineer- 
ing team for the development of mwm allowed lor rapid 
and effective progress once the functionality was defined. 

Widgets and Windows 

There are two principal levels in which a programmer 
can write a user interface for an X client: the high level 
using a widget library like the OSF/Motif widgets and the 
low level using the X library. Widgets provide high-level 
objects (like menus and buttons] that embody the semantics 
of specific user interactions, and the X library provides 
only basic: window functionality. Since the HP window 
manager user interface was implemented using a mixture 
of widgets and the X library, mwm was implemented using 
a similar mixture of libraries. 

Mwm uses the OSF/Motif widgets to implement its menus. 
This provides appearance and behavior consistent with 
applications that also use the OSF/Motif widgets. It also 
leverages the engineering effort that went into the design 
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Fig. 6. Exploded view of an mwm window frame. 
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and development of the menu widgets. 

Mwm does not use any widgets for the window frame 
components (title bar, resize handles, and border). To un- 
derstand why. it is necessary to examine the decision made 
for hpwm. First, at that time, the available widgets did not 
offer enough control over the thickness of the 3D beveling 
(the top shadow and bottom shadow highlights) to give the 
desired 3D effect. The window frame has oddly shaped 
pieces and complicated joints that require explicit drawing 
by the window manager. Also, the visual design requires 
single-pixel beveling between components of the window 
frame. 

Second, although using multiple widgets as buttons for 
the frame decoration simplified some aspects of event han- 
dling, it complicated changing the color of the entire win- 
dow frame. Some window managers change only the title 
bar appearance to indicate the active window. However, 
this can be difficult or impossible to spot depending on 
the size of the window and the degree to which it is 
obscured. Mwm and hpwm change the color of the entire 
frame to indicate keyboard focus. Thus, the functional and 



performance needs of hpwm required a solution other than 
using the widgets available at the time. 

It is important to note that with the latest version of 
OSF/Motif widgets, most of the objections that caused the 
initial decision not to use widgets for the window frame 
have gone away. For example. OSF/Motif provides widgets 
called "windowless gadgets" that provide better perfor- 
mance than the widgets with windows that we used. How- 
ever, there are still some mwm user interface requirements, 
such as the resize cursors, that require either widgets with 
windows or special processing. 

An mwm window frame consists of ten windows for draw- 
ing, cursor presentation, and event handling (see Fig. 6). 
The main frame window has the root window as its im- 
mediate parent. It is an input/output window and is the 
window to which frame drawing is done. Above the frame 
window are eight input-only windows for the resize han- 
dles. Each of these windows has its own cursor to indicate 
the type of resize that can be started in that area. The next 
layer up includes an input-only title window which is used 
to display a different cursor for the title area and partially 



1 This is a fragment of an .Xdefaults file containing some 
= representative settings for the OSF/Motif window manager. 



# General Appearance and Behavior Resources 
f 

i Set private mwm button and key bindings (see .mwmrc) . 

Mwm*buttonBindings : MyButtonBindings 
Mwm*keyBindings: MyKeyBindings 

# Remove active label from icon decoration and tighten 
| icon placement. 

Mwm*iconDecoration: image label 

Mwm*iconPlacement: left bottom tight 



i Component Appearance Resources 

! 

| Use these colors on the "active" window 

# (the window that gets keyboard input) . 

mwm*activeBackground: turquoise 
mwm* active Foreground: white 

# Use this color scheme on "inactive" windows. 
mwm*background : cadet blue 

# font to use for Mwm (different fonts for titles, menus and icons) 

Mwm*fontList: helvRlS 
Mwm*menu*title*f ontList: ncenR24 
Mwm*icon*f ontList: helvB14 



# Client -Specific Resources 

i 

# + HPterm gets a special icon image 

# + Reduce frame decoration for xload and xclock. 

Mwm*HPterm*iconImage: /users/keith/Bitmaps/terminal . xbm 

Fig. 7. A sample resource file 

Mwm*XClock*clientDecoration: border showing some sample configura- 

tions lor the OSFIMolil window 
Mwm*XLoad*clientDecoration: menu title minimze manager 
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obscures the upper resize windows. This layer also in- 
cludes a base window on which the client window sits. 
The base window partially obscures the lower resize win- 
dows and is used for drawing the client matte if one is 
specified. The client matte is a feature of mwm that allows 
the user to create an extra level of distinguishability for a 
window by specifying a color for the area below the title 
bar window shown in Fig. 6. An example of this feature 
is illustrated by the strip labeled optional matte in Fig. 2. 

The primary reason there are so many windows is to get 
the desired cursor behavior. As the pointer moves into each 
resize area, the cursor changes to indicate the type of resize 
that can be started in that area. This is accomplished in 
mwm by creating input-only windows that overlay the 
graphics in the frame window. Each window is created 
with a different cursor attribute. A benefit of this, from 
mwm's point of view, is that the X server takes care of chang- 
ing the cursor shape when the pointer enters or leaves these 
windows. Careful overlapping of the title bar window and 
the base window clips the corner resize areas to their 
characteristic nonrectangular shapes. 



Configuration 

The mwm approach to configuration can be characterized 
in terms of consistency, flexibility, performance, and usa- 
bility. These attributes were achieved using the following 
techniques. 

• The mwm configuration is based on the values of re- 
sources set in the resource files. Mwm resource names 
are consistent with the standard OSF/Motif widget 
names. The names are defined such that a single entry 
in a resource file can be used to specify values for related 
resources. For example, the background color used for 
all window manager components can be specified with 
one resource. 

■ Most configuration overhead occurs at start-up and is 
avoided during user interaction, when quick feedback 
is required. 

■ All mwm resources have default values that are consistent 
with the standard Presentation Manager behavior and 
3D appearance. 

Three types of resources are processed by mwm: general- 
behavior resources, component-specific appearance re- 



# This is an annotated fragment of an .mwmrc file 
t 

§ Workspace menu description 

# This menu is posted by a button binding (see MyButtonBindings below) 
f It offers the options of 

# + starting an hpterm terminal emulator (80 columns by 42 lines) . 
t + starting an hpterm that is logged into a remote system (bill) . 

# + starting an hpterm that is logged into a remote system (dave) . 

# + refreshing the entire display 

# + restarting the window manager 
# 

Menu Workspace 



"Workspace Menu" 



hpterm 
bill 
dave 
no-label 
Refresh 
Restart 



f .title 



f . exec "hpterm 
f.exec "hpterm 
f . exec "hpterm 
f . separator 
f .refresh 
f .restart 



=80x42&" 

=80x42 -T bill -n bill -e rlogin bill" 
=80x42 -T dave -n dave -e rlogin dave" 



I 

# key binding descriptions 

I This key binding replaces the default Shift-Esc binding 

I that posts the window menu. 

# 

keys MyKeyBindings 

Alt<Key>Escape icon | window f.post_wmenu 



button binding descriptions 
These button bindings 

+ post a workspace menu over the root window (screen background) 
+ provide an accelerated move function for icons and windows 
+ provide an accelerated resize function for windows 



Buttons MyButtonBindings 
{ 

<BtnlUp> root 
Alt<BtnlDown> icon | window 

Alt<Btn2Down> window 

} 



f .menu WorkMenu 
f . move 
f . resize 



Fig. 8. A portion ol a We defining 
mwm general behavior resources 
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sources, and client-specific appearance and behavior re- 
sources. Fig. 7 shows a portion of a file with some sample 
resource settings. 

General-Behavior Resources. General-behavior resources 
are used to define window manager policies such as direct- 
ing keyboard input to a particular client window and 
specifying when to install a client window's color map. 
Button and key associations* to window manager functions 
are also specified. For example, pressing the left mouse 
button with the pointer over the root window can be con- 
figured to post a menu. The general -behavior resources are 
completely processed when mwm is started. 

Fig. 8 shows a portion of the mwm resource file used to 
define the button and key associations declared in the sam- 
ple Xdefaults file shown in Fig. 7. The first part of the re- 
source file, labeled Menu Workspace, defines the appearance 
and the functions associated with the menu shown in Fig. 
9. For example, for the menu item hpterm. the function I exec 
is executed when hpterm is selected, and the field "hpterm 
a 80x42&' defines the HP-UX command that is executed by 
f.exec to start a new hpterm terminal emulator that is 80 
columns by 42 lines in size. The key and button bindings 
define the event (key or button selection), the context 
(where the event occurred), and the action associated with 
key and button selections. From the key binding descrip- 
tion in Fig. 8, the key sequence Alt ESC entered while in 
an icon or window context would cause the Window menu 
to be displayed. 

Component-Specific Appearance Resources. Mwm high- 
level components include the window frames, icons (small 
representations of client windows), and window manager 
menus. These components use the same set of appearance 
configuration resources. The resources specify the colors 
and textures to use for 3D appearance and the font to use 
for displaying text. Defining the 3D appearance of a compo- 
nent can involve specifying the texture and color for the 
foreground, the background, the top shadow, and the bot- 
tom shadow of the component. Default component-specific 
appearance resources can be used to avoid specifying any 

•Also called key timdings 
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hpterm 




bill 




dave 




Refresh 




Restart 





Fig. 9. The Workspace menu described in the .mwmrc file in 
Fig 8 



resources for a monochrome system, and only the back- 
ground color on a color system. On a color system the top 
shadow, bottom shadow, and foreground colors are gener- 
ated algorithmically. The algorithm generates an effective 
3D visual appearance based on a background color. New 
colors are generated by shifting the RGB values of the back- 
ground color. The values are shifted to make the top shadow 
color lighter, the bottom shadow darker, and the foreground 
color much darker than the background color. 

The window frame and icon components have a set of 
appearance resources for both active and inactive states. 
A component in the active state can receive keyboard input, 
and a component in the inactive state cannot. In the case 
of a window frame, the client window receives the keyboard 
input. For human factors and performance reasons there 
is a single 3D color scheme for active components and a 
single color scheme for inactive components. Multiple, 
client-specific color schemes for active and inactive states 
led to problems with identifying the client window that 
was supposed to receive keyboard input. Also, interactive 
performance is maintained by allocating all component 
colors and graphics contexts (graphics state information 
used in X drawing requests) at start-up time. 
Client-Specific Appearance and Behavior Resources. Re- 
sources used by the window manager to customize compo- 
nents for particular client windows are client-specific re- 
sources. The image in the icon representation of a client 
window can be specified. Client-specific colors can also 
be specified to color the client icon image and the 3D matte 
that fits within the window frame. Client-specific resources 
are retrieved based on the resource name or class of a client 
window. The resulting X resources and window manager 
components are cached to avoid resource processing over- 
head when several clients of a particular name or class are 
run. This enhances performance because client windows are 
placed on the display frequently during user interaction. 

Event Processing 

Mwm event processing is designed to handle different 
types of events and event contexts. The events that are 
processed include button presses, pointer motion, window 
destruction, and many more. Event contexts deline the lo- 
cations where the events occurred. These locations include 
the root window, widgets, nonwidget window manager 
components, the window frame, an icon, and client win- 
dows. The window frame has subc.ontexts such as the sys- 
tem menu button, the resize border handle, the title, and 
the minimize button. 

Table I lists some events that are processed, the contexts 
they occur in, and the actions taken when Iheevent occurs. 

Events with a root window context generally involve 
newly displayed windows, destroyed client windows, or 
the invocation of a window manager function that is not 
client-specific (e.g.. repaint the screen). Events for mwm 
menus have a widget context. Events with a nonwidget 
context are generally on the window frame and are often 
related to user interaction with the direct manipulation 
components such as the resize handles. Events with a client 
window context are typically notifications about the actual 
or desired state of a client window. 

The event-processing loop for mwm has the following 
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Table I 

Events, Contexts, and Actions 



Event 



Map 
Window 



Window 
Destroyed 



Context 

Decorate 
the window 
with a new 
frame and 
place it on 
the display. 

Remove the 
frame from 
the display 
and recover 
resources. 



Widget 
Context 



Non- 
widget 
Context 



Client 
Window 
Context 



Button 


Post (show) 


Activate 


Press 


menu. 


frame com- 






ponent 






button or 






resize 






handle. 


Pointer 


Move 


Move or 


Motion 


selection 


resize frame 




cursor. 


outline. 


Button 


Unpost 


Commit 


Release 


(hide) menu, action. 



Change 
Color Map 



Install 

color map for 
window. 



flow of control. 

■ Use the Xt Intrinsic function XtNextEvent to retrieve the 
next event sent by the X server. 

■ Identify the event context. Events are always reported 
relative to some window. The X context manager, which 
is accessible through X library functions, is used to as- 
sociate mwm contexts and data with the window iden- 
tifiers provided in events. 

■ Dispatch nonwidget events to the appropriate event 
handler and dispatch widget events using the Xt Intrinsic 
function XtDispatchEvent. 

» Go back lo the start of the event loop to get the next event. 
Mouse Event Processing. Much of the behavior of the win- 
dow manager interface is based on how mouse events are 
processed. Mwm divides mouse event processing into two 
categories: mutable behavior event processing and immu- 
table behavior event processing. 

Immutable behavior is buill into mwm and is associated 
with the direct manipulation features (title bar, resize han- 
dles, etc.) of window frames and icons. Each direct manipu- 
lation feature has its behavior encapsulated in mwm event 
processing. Button press-and-release events and mouse mo- 
tion events that occur with a context corresponding to a 
direct manipulation feature are processed by the event 
handler for that feature. 



Mutable behavior event processing is based on user 
specification of mouse event associations with window 
manager functions. For example, button three of the mouse 
can be associated with the minimize function such that 
whenever button three is pressed with the mouse pointer 
over any part of the client window or window frame, the 
window will be minimized. 

Mwm maintains a table that associates mouse events with 
window manager functions, and it uses this table for decid- 
ing which window manager function to invoke. 
Keyboard Input Focus Event Processing. The window with 
the keyboard input focus is known as the active window. 
What this means is that when a key is pressed, the input 
is applied to the window with the keyboard input focus. 
Moving the keyboard input focus between windows is an 
important window manager function. 

Two behaviors are supported by mwm for setting the 
keyboard input focus: explicit selection and pointer-rela- 
tive selection. * Explicit selection means that a specific win- 
dow is designated to be the keyboard input focus window. 
Explicit selection of the input focus is Presentation Man- 
ager behavior. For pointer-relative selection, the window 
under the mouse pointer automatically becomes the 
keyboard input focus window. This behavior is favored by 
many technical users. 

Very different event processing is needed to handle the 
two different keyboard input focus behaviors. Setting the 
keyboard input focus in pointer-relative mode is done using 
enter and leave window events. When the pointer enters 
a window frame, mwm receives an enter window event. 
Mwm responds by making a request to the X server to cause 
delivery of keyboard input to the client window. As long 
as the pointer remains over the window frame (or the client 
window), keyboard input will be delivered to the client 
window. This maintains the illusion that the window frame 
is just another part of the client window. When the pointer 
leaves the window frame, a leave window event is received. 
This is usually followed by an enter window event as the 
pointer enters the root window or another window frame. 
Mwm responds by resetting the keyboard input focus ap- 
propriately. 

Event processing for explicit selection of the keyboard 
input focus primarily involves button press and key press 
events as opposed to enter and leave window events. When 
a button press event is received by mwm and the context is 
a client window that does not have the keyboard input 
focus, mwm calls the X server to cause the delivery of 
keyboard input to the client window. 

Mwm has to take care when it is processing button press 
events. Usually button events go to the window that is 
under the mouse pointer at the time the button is pressed 
or released. This means that if the pointer is over a client 
window and the button is pressed, the client window 
would normally get the button press event and mwm would 
not see an event. Mwm handles this by establishing a passive 
grab of the button event when it is generated in the client 
window context. A passive grab of the button causes the 
event to be delivered to mwm and not to the client window 
(see Fig. 10a). Mwm has effectively stolen a button event 
that would normally belong to the client window. 

■Also known as tracked listener ana real-eslate driven 
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This is not very friendly because the stolen event is often 
a mouse button 1 press event which, according to Pres- 
entation Manager, is also used to do selections of user 
interface components in the client window. Mwm redeems 
itself by making the button event available to the client. 
After mwm sets the keyboard inpul focus, it replays the 
button press, causing the event to be delivered to the client 
window (see Fig. 10b). Mouse event processing by the 
server is then allowed to continue, and mouse events that 
occur after the button press are delivered to the client win- 
dow (if the client window is interested in the events), While 
a client window has the keyboard input focus, mwm turns 
off its passive grab request for a button press. 
Interactive Pointer Tracking. A direct manipulation inter- 
face has to work hard to provide good feedback to the user. 
An example of this occurs during interactive moving or 
sizing of windows in mwm. Mwm draws a frame outline that 
tracks the new position or size of the window as the user 
moves the mouse around. Making this operate smoothly 
and efficiently requires some interesting event processing. 

All X window managers provide a feedback mechanism 
like the one described above. Many do so by polling the 
position of the pointer (mouse cursor) and drawing a new 
outline (erasing the old) when the position changes. This 
has the advantage of keeping the window manager and the 
server synchronized, providing smooth behavior. The dis- 
advantage is that the polling continues when the pointer 
is not moving, using up network bandwidth if the window 
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Fig. 10. (a) Mouse input stolen by mwm using a passive 
grab The short arrow indicates that the button event never 
makes it to the client, (b) Mouse input intercepted by mwm 
and replayed. 



manager is running remotely. 

The first implementation of hpwm. forerunner of mwm, 
departed from polling by requesting the server to report 
pointer motion events only when the pointer moved. Thus 
the drawback of polling was avoided. However, when the 
pointer moves, a large number of events must be processed. 
This was not a problem on medium-to-high-performance 
workstations that could keep up with the flood of events, 
but a problem did occur on low-performance machines, 
particularly X terminals. The time to process each motion 
event was longer than the time to generate a new one. 
causing the user to observe a window outline that would 
fall behind the motion of the pointer. 

The solution to the problem, implemented in mwm (and 
a later hpwm). is to request the X server to send pointer 
motion hints, which are a special type of pointer motion 
event. In this mode of operation, the X server only sends 
pointer motion hints in conjunction with certain other 
events, such as window exit and entry. The X server also 
sends a pointer motion hint when the pointer moves from 
the last position queried by mwm. Each time a pointer mo- 
tion hint is received, mwm acknowledges it by querying the 
position of the pointer. It then moves the pointer outline 
based on the values returned by the query. Tracking the 
pointer position with pointer motion hints is more expen- 
sive than polling when the pointer is moving, but it avoids 
the polling burden when the pointer is not moving. 

Adopting a Client Window 

Adopting a window refers to the process that mwm goes 
through when it initially encounters a window that it does 
not yet manage. This happens with I he set of client win- 
dows that are on the display before mwm is started, as well 
as with clients that are started after mwm is already running. 
For each window thai it adopts, mwm collects information 
from the client and the resource data base thai affects the 
appearance of the window border, the placement of the 
window on the screen, and the window's behavior in re- 
sponse to user actions. 

Communication between an X client and an X window 
manager occurs through events and properties (special in- 
formation associated with a window). Among the events 
that are processed by mwm are those that begin or terminate 
management of X clients. The properties allow the client 
to indicate placement, decoration, and behavior informa- 
tion. 

Mwm becomes aware of a new client when it receives the 
client's redirected request to display (or map) its top-level 
window. Mwm responds to this event by: 

■ Examining several client window properties 

■ Constructing a window frame and icon for the window 

■ Reparenting the client window to the mwm window frame 

■ Placing the client window on the display. 

Several properties are used in this client-window man- 
ager communication. Some are listed in Table II. 

The initial position and size of a window can be set 
either programmatically or interactively by the user. This 
information is passed to mwm in the WM_ NORMAL. HINTS 
property of the client window. The value of this property 
is what determines how mwm places the window. Mwm will 
let the user place the window interactively if mwm's interac- 
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Table II 
Window Properties 
Property Use 

_M0TIF_WM_HINTS Frame decoration and function 
preferences 

_MOTIF„WM_MENU Modify window menu 

WMLCLASS Client class for fetching resources 

WMJHINTS Icon image 

WM_ICON_NAME Icon name 

WMJCON_SIZE Icon sizes preferred by window 

manager 

WM_NAME Client window name 

WM_NORMAL_HINTS Window position and size 

WM_PROTOCOLS Client-window manager 

communication 

WM_STATE Window manager state for client 

WM_TRANSlENT_FOR Secondary window indicator 



live placement is enabled and if the initial position has 
been set programmatically. However, if the initial position 
has been set by the user (e.g., via a command-line option), 
interactive placement will not be done even if it is enabled . 

Mwm manages windows, not clients. If a client uses sev- 
eral top-level windows, mwm will treat them all equally 
even though they may have different purposes. However, 
a client may indicate a secondary top-level window, such 
as a dialog box. by placing the WM_TRANSIENT_FOR property 
on il. Mwm will decorate a window with this property dif- 
ferently, using a separate decoration resource for secondary 
windows. Mwm will not place a secondary window inter- 
actively. 

In addition to reading properties when the window is 
adopted, mwm tracks changes to some of the properties 
while the client is running. The client may change the 
name displayed in the title bar by changing the WM_NAME 
property. Similarly, the client may change the name dis- 
played i n the icon by changing the WM_ICON_NAME property. 
Window geometry (i.e., size, position, and resize incre- 
ment) changes are also tracked in WM_NORMAL_HINTS to 
make sure that resize units are properly reported. For exam- 
ple, a terminal emulator may resize its window to display 
function keys, but the number of text rows reported as the 
window size should not change. 

Menu Handling 

Mwm supports both client-specific and general-applica- 
tion menus. The contents of client-specific window menus 
and general-application menus can be specified by the user. 
The user can also specify the button or key event that 
causes a menu to be posted and the context for the event 
(e.g.. post a utility menu when mouse button 1 is pressed 
with the pointer in the title area of the window frame). 
Everything that can be done with menus using a mouse 
can also be done using a keyboard. 

Presentation Manager behavior includes a client-specific 



window menu that is posted using the window menu but- 
ton on the window frame. The window menu is like a 
pull-down menu. It appears below the window menu but- 
ton when the pointer is moved over the window menu 
button and the selection button (on the mouse) is pressed. 
A selection is made by dragging the pointer to a menu item 
and releasing the selection button. A client-specific win- 
dow menu can also be posted by a button or key event in 
the client icon context. 

To the user it may seem that mwm supports a large number 
of menus. This is because each client window has a menu 
that is posted from the window menu button, and each 
client icon has a menu that can be posted with a key press 
(typically Shift ESC). There are also menus that are com- 
monly used to start clients and to perform various window 
management functions (e.g., change the stacking order of 
client windows). The heavy use of menus, combined with 
the relatively high performance cost of making menus, led 
to the design of a menu cache for mwm. A menu cache is 
possible because many menus have the same menu items. 
Also, the flexibility of the OSF/Motif menu widget allowed 
mwm to use a pop-up menu type for all the menus. Mwm 
uses the OSF/Motif pop-up menu type to implement win- 
dow menus and simulates pull-down menu behavior when 
a menu is posted using the window menu button. 

Mwm keeps a list of menu specifications. When mwm 
makes a menu it starts with a particular menu pane specifi- 
cation. The workspace menu entries given in Fig. 8 illus- 
trate a menu specification. Other menus can be specified 
to cascade from the starting menu (see Fig. 11). When a 
menu is made, an association is made between the menu 
and the initial menu specification. Subsequent calls to 
make the same menu will return the menu that is already 
built. The key to making this work is the capability of mwm 
to adjust the characteristics of the menu dynamically so 
that the menu is set up correctly for the context in which 
it is posted. 

Mwm adjusts the following menu characteristics: 
■ The active and inactive appearance and behavior of 
menu items are matched to the context in which the 
menu is posted. Menu items that are not applicable in 
a particular context are grayed out and are not selectable. 
For example, a menu item that minimizes a client win- 

(conlmued on page &4) 
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Fig. 11. The Systems menu is cascaded from the Workspace 
menu because of the entry in Workspace that calls the Systems 
menu. 
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Interclient Communication Conventions 



The X Window System Version 1 1 (X) was designed lo be a 
platform on which windowed application environments could be 
built. It provides a basic set of mechanisms for building these 
environments and does not impose any particular user interface 
behavior With a minimal set of constraints on behavior an X- 
based application (X client) may be usable m isolation out unable 
to coexist with other X clients. Coexistence entails civilized shar- 
ing of limited resources (eg. the physical color map) and the 
use of standard mechanisms for exchanging information (e g , 
cutting and pasting text) A window manager can enforce coexis- 
tence of X clients in areas such as the use of screen space and 
keyboard input, but even a window manager does not have 
absolute power to maintain order An unfriendly X client could 
grab the X server and prevent other X clients from getting input 
or doing output. 

Inter-Client Communications Conventions Manual 

Early in the development of X. representatives from the different 
companies working on or with X started meeting to address the 
problem of X client coexistence This group has been officially 
sanctioned by the X Consortium to develop mterchenl communi- 
cation conventions. The conventions that have been developed 
are documented in the Inter-Client Communication Conventions 
Manual (ICCCM). ICCCM compliance has become a key design 
criterion for X clients The development of the ICCCM is ongoing 
and the general goals that shape this development include: 

■ Improving client coexistence in areas of potential contention 

• Tracking the evolution of the X Window System and X clients 
and providing new conventions that are generally applicable 

■ Adding X Window System support for new conventions. 

■ Ensuring that all ICCCM changes are backwards compatible. 
This means lhat all previously defined conventions are main- 
tained, and old conventions are changed only when they 
clearly cause incorrect behavior 

Client-To-Window-Manager Communication 

Many conventions are documented m the ICCCM However, 
the conventions that have received the most attention by X client 
developers have been those dealing with client-to-wmdow-man- 
ager communication A key goal of the mwm design was ICCCM 
compliance. X clients that are ICCCM compliant can coexist in 
a predictable manner with mwm and with each other Window 
properties are one of the X mechanisms for chent-to-window- 
manager communication A window property is a collection of 
information of a particular lype lhat is associated with a window 
Clients associate, by convention, several properties with Iheir 
windows to communicate wilh the window manager. Noteworthy 
examples of properties that are used for client-to-wmdow-man- 
ager communication are wm.normal. hints and wm_proto- 
COLS The WM.normalhints property deals with window size 
and positioning, and WM.PROTOCOLS deals with public or private 
window manager communication protocols 

Client Window Size And Position 

The WM_ normalhints property is used by a client to give a 
hint to the window manager on how the clienl window should be 
positioned on the screen and what its size should be. The window 
manager enforces how a client is positioned and sized on the 
screen Some window managers may enforce a policy where all 
client windows are tiled on the screen (displayed without overlap- 
ping), or where windows are not allowed to be displayed with 



part of the window off the edge of the screen The wm_normal_ 
hints properly provides the window manager with a siamng 
point from which it then applies the screen layout policies An 
ICCCM compliant window manager can ignore some or all of 
Ihe information containeo in the wm_normal_hints property An 
X client should be designed to be robust enough lo work in 
environments where this is the case This demand on X clients 
is based on an ICCCM principle lhat the user is in control of the 
user interface, not the X clienls 

The wm_normal_hints property contains the following pieces 
of information- 

■ Minimum and maximum window sizes These are reasonable 
minimum and maximum sizes for the window. Mwm uses the 
maximum size when a window is maximized 

■ Base and increment window sizes. The overall window size is 
ihe base size plus some number of increments Mwm adjusts 
a window size to meet this constraint when the window is 
initially placed on the screen or following resizing by the user 
This is especially useful when the window is associated with 
a terminal emulator X client. The base window size usually 
includes the height of the softkeys. The increments are set to 
be equivalent to the heighi and width of one of the characters 
displayed in the terminal emulator window (terminal emulator 
X clients use fixed-size fonts in which all characters are the 
same size) 

■ Minimum and maximum window aspect ratios. The aspect 
ratios indicate allowable values for the ratio of the window 
width to the window height. For example, an X clienl can indi- 
cate that it would always like to be displayed in a square 
window (the aspect ratio is 1:1), 

■ Anchor point for window placement. The anchor point for plac- 
ing a window allows an X client to specify how the window 
position should be interpreted. This is useful in Ihe case where 
a window manager adds a frame around the X client window 
and adjusts the position of Ihe X client window on the screen 
The X client can specify an anchor point such that a corner 
or side of the X clienl window, including the window manager 
frame, is placed al a particular absolute location on the screen 
In general, mwm uses Ihe wm_normalhints information wilh 

little or no change to place an X client window. Adjustments are 
only made if the user requests some refinement of the mwm 
window placement policy (e g , the user requests that windows 
be interactively placed when ihey are first displayed). In placing 
an X client window on Ihe display, mwm first determines a desir- 
able window size, which is usually the window size specified by 
the X client Mwm then retrieves the WM NORMALHINTS property 

The processing of Ihe wm.normauhints property vanes 
based on the version of the ICCCM that the associated client 
implements. Mwm uses the size of the property in figuring out 
which version of the ICCCM to use This allows mwm to be back- 
wards compatible in complying with the ICCCM 

Client and Window Manager Protocols 

The wm^protocols property is used by an X client to indicate 
inleresl in public or private window-manager-to-client communi- 
cation protocols In general, these protocols are used to inform 
an X client of some window manager action thai has occurred 
or is about to occur (e.g., the window system is about to be 
terminated) Public protocols are registered by the X Consortium, 
specified in the ICCCM, and supported by most, if not all, ICCCM 
compliant window managers Private protocols are specific to a 
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particular window manager Private protocols that have high utility 
and widespread acceptance by X clienl developers usually be- 
come public protocols. 

The wm.protocols property is formatted as a list of protocol 
identifiers. Many window managers, including mwm. keep track 
of X client changes to the property. This allows an X client to 
participate only in those protocols that it requires at a particular 
time. The WM_protocols list can accommodate any number 
and mix of public and private protocols. 

The wm_delete_window protocol is a commonly used public 
protocol This protocol is used to inform X clients that a request 
has been made (probably by the user) to get rid of an X client 
window. This protocol is used by window managers to implement 
a clear and consistent user interface for getting rid of windows. 
Typically, deleting a window also includes deleting the X client 
that is associated with the window Mwm uses the wm_DElete_ 



(continued f'om page 22) 

dow is grayed out if Ihe menu is posted in the icon 
context. 

■ A menu is placed in keyboard traversal mode to allow 
keyboard manipulation of the menu. However, if a menu 
is not posted using a key press, the menu is not placed 
in traversal mode. 

■ A menu is configured to have particular key and button 
events select a menu item and unpost the menu. 

■ A menu is posted at a particular screen position (e.g., 
below the window menu button in a window frame). 
Mwm keeps track of the currently configured characteris- 
tics of a menu and does the minimal amount of adjust- 
ment that is necessary before posting the menu. 

Component Graphics 

The window frame provided by mwm for decorating client 
windows consists of a number of components representing 
different window management functions. The functional- 
ity and layout of Ihe components are the same as in Presen- 
tation Manager. However, mwm enhances the appearance 
of the frame by adding the 3D appearance. 

It is important for mwm to be as fast as possible to imple- 
ment a good direct manipulation interface. The two princi- 
pal things that were done to speed up the graphics render- 
ing were to minimize the number of X protocol requests 
to draw the frame, and to do all the drawing to one window. 

A fully configured mwm window frame consists of a bor- 
der and a title bar. The border is divided into eight resize 
handles. The title bar is divided into boxes (or gadgets) for 
the system menu, the title text, and the minimize and 
maximize functions. The height of the title bar and the 
drawings inside the gadgets are scaled to match the height 
of the font used for the text in the title bar. 

A frame with the 3D look may have as many as four 
colors displayed at once. These are the background, the 
foreground (title text), and the top shadow and bottom 
shadow colors (see Fig. 12). The background color makes 
up the majority of the color visible in a frame. Mwm sets 
the background color of a frame by setting the background 
attribute of Ihe frame window. The background of all the 
frame components is set in one X graphics call. Once this 
attribute is set, the X server takes care of painting the back- 
ground of the window in response to exposure events. 

Graphic contexts are used to store much of the informa- 



window protocol to close a window The mwm close function can 
be accessed from the standard window menu thai is posted by 
pressing Ihe window menu button in the client window frame. If 
the close funclion is invoked on a client that does not participale 
in the WM_DELETE_WINDOW protocol, mwm uses the X request 
XKHiChent to get rid of the window and terminate the clienl. In this 
case Ihe clienl finds out thai il has been terminated but cannot 
prevent or delay Ihe termination. This is not appropriate for clients 
thai would like lo interact with Ihe user on termination, or clients 
that have multiple windows that can be independently terminated 
If a client does participate in the WM_delete_window protocol, 
mwm sends a termination request message to the client indicating 
that the window is to be terminated. II is then up to Ihe client to 
determine how to deal with the window, because mwm takes no 
further action. Well-behaved clients immediately remove the win- 
dow from Ihe screen or prompt the user for confirmation 



tion required by the X graphics routines. This includes 
items such as colors, line styles, and clip regions. Mwm 
creates several graphic contexts for use in drawing the 
frame. These graphic contexts may differ in foreground 
color and fill tile. They are created when the window man- 
ager starts up and are used for all the window frames. When 
mwm draws a differently colored part of the frame, it passes 
a different graphic context lo Ihe graphics drawing routine. 

The title text is usually drawn in one XDrawStnng call 
using the graphic context containing the foreground color. 
If the text is too long for the available space, then the text 
is truncated by setting a clip rectangle into the graphic 
context before calling XDrawSlring. 

The remainder of the frame is made of the top and bottom 
shadow colors. This includes Ihe outer 3D shadowing, the 
separations between Ihe resize handles, the edges of the 
title bar buttons, and the images inside the system 
minimize and maximize buttons. This drawing is done 
with only two calls to XFillRectangles. 

XFillRectangles takes, among its arguments, a list of rectan- 
gles and a graphics context. Mwm generates two lists of 
rectangles for top and bottom shadows when a frame is 
built. This occurs whenever a frame is needed for a new 
window, or when a window has been resized. To make 
this task simpler to code, two helper routines were con- 
structed to add data to an existing pair of lists. One routine 
adds the top and bottom shadows to construct rectangular 
features. The other routine adds the top and bottom 
shadows to construct the corner resize handles. The 
shadowing for the entire frame is constructed out of mul- 
tiple calls to these two routines. 

Mwm always redraws the entire frame in response to an 
exposure event. In the best case, this takes three X graphics 
calls for drawing the text and the top and bottom shadows. 
If the text is clipped, then two more X calls are required 
for setting and clearing the clip rectangles. If the back- 
ground color of the frame changes, then two additional 
calls are needed to set the frame window background attri- 
bute and clear the window to the new background. The 
common case of setting or clearing the focus indication on 
a window frame takes five X graphic calls. 

The performance of this frame redrawing algorithm has 
been adequate. A possible optimization would make the 
exposure event handling smarter by only drawing those 
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areas thai need to be drawn. This would require either 
generating a new list of rectangles for the exposed region, 
or picking out the affected rectangles from the list of rect- 
angles for the whole frame. Since X drawing calls map into 
X protocol requests (which can be computationally expen- 
sive), the optimization would have to avoid generating 
more X protocol requests than the approach taken above. 

Testing a Window Manager 

Mwm has a programmatic interface that is used by clients 
and an interactive interface for users, The testing ot mwm 
needed to cover both of these interfaces. The approach to 
testing the programmatic interface involved writing a 
number of special-purpose clients that systematically gen- 
erated all of the events that the mwm programmatic interface 
handles. These programs were run for each regression test 
as mwm progressed through its various development re- 
leases. 

The testing of the interactive mwm interface required a 
much different approach. The interactive nature of the in- 
terface precluded the use of test programs. Testing could 
have been accomplished by developing test scripts that 
testers would follow for each regression cycle and each 
tested hardware configuration. However, this is an ex- 
tremely tedious and expensive approach to testing. 

Fortunately the Xtm (X test monitor) testing tool was de- 



Fig. 12. The lour colors involved 
in achieving the 3D look for a 
frame 

veloped for testing interactive X clients. Xtm is based on 
the record-replay software testing technique. 4-5,8 In this 
technique human interactions with the system are recorded 
in a file and replayed later for regression testing. Xtm records 
all mouse and keyboard interactions and saves them in an 
interactive test script file. The tester can al any time save 
snapshots of all or part of the screen. For regression testing 
the Xtm interactive test scripts can be replayed. Xtm com- 
pares the saved screen images with the replay screen images 
and flags any differences. A tester only has to spend lime 
recording the interactive test script and checking the results 
of the automated regression tests. Use of Xtm also allowed 
repeatable testing. A user could not be expected to move 
a pointer in exactly the same way or remember what a 
screen looked like down to a single pixel each lime a test 
script is followed. 

Mwm testing also benefited from the wide distribution it 
received through OSF. Mwm was made available to a sizable 
number of people at OSF member companies including 
HP. These users had a variety of software and hardware 
environments as well as different patterns of use and expec- 
tations from a user interface. Their input provided a useful 
adjunct to the testing done using Xtm. 
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Programming with HP OSF/Motif Widgets 

The HP OSF/Motif widget library makes it easy for a 
developer to create applications with a graphical user 
interface that has a consistent appearance and behavior. 

by Donald L. McMinds and Benjamin J. Ellsworth 



THE X WINDOW SYSTEM (usually referred to simply 
as X) is widely recognized as the industry standard 
window system for UNIX-system-based workstations 
X*s greatest attribute is the fact that applications written 
for one vendor's platform will run on almost any other 
platform without modification. X provides a root window 
within which smaller windows can be displayed. A number 
of applications can be run simultaneously and each appli- 
cation can have any number of windows. A workstation 
screen with a typical assortment of windows is shown in 
Fig. 2 on page 7. 

The X Window System is composed of a set of library 
functions known as Xlib. Xlib is the heart of X and it can 
be compared to an assembly language. Like assembly lan- 
guage programming, creating a user interface using only 
Xlib can be tedious and cumbersome (an example of Xlib 
programming is provided later in the article). To overcome 
this problem, the X designers created a second set of func- 
tions called the Xt Intrinsics or the X toolkit. The Xt Intrin- 
sics use the Xlib functions to provide a higher-level set of 
functions that make user interface programming easier. The 
next library in the hierarchy, widgets, was designed to use 
both Xlib and the Xt Intrinsics to relieve the programmer 
of much of the extra work required to use these functions. 
The relationship between the two sets of X functions (Xlib 
and Xt Intrinsics) and widgets is much the same as the 
relationship between a computer's assembly language and 
a high-level language such as C. 

The user communicates with X through the window 
manager. Depending on the request, the window manager 
communicates directly with one of the lower-level compo- 
nents in the hierarchy shown in Fig. 1 or with the X client. 
The window manager is really just another X client (al- 



though admittedly a very special one). 

The box on page 27 provides more information about 
the evolution and development of widgets. This article 
describes some characteristics of the HP OSF/Motif widget 
library and shows how to write a program using this library. 

Widgets 

Widgets provide a base upon which the programmer can 
build an application user interface that has a consistent 
behavior and appearance. Widgets have a hierarchical class 
structure. Each widget has some resources of its own and 

Icontmuefl on page 29) 



HP OSF/Motif Window Manager 
Other X Clients 





HP OSF Motif Widgets 



Xt Intrinsics 



X Window System 



Operating System and Network 



Hardware Platform 



Fig. 1. The X Window System and other components in the 
OSF/Motif environment The dashed line indicates that other 
X clients can either be managed by the window manager or 
run independently of the window manager 
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The Evolution of Widgets 



The development and acceptance of any new technology in 
the software industry as a standard is an evolutionary process 
that is driven by such things as competition, new technologies, 
and the desire for interoperability over a wide variety of hardware 
platforms This is the case with HP's OSF/Motif widget toolkit 
This toolkit and the Xt Intrinsics were developed to provide a 
standard set of tools for implementing user interfaces for UNIX- 
system-based systems running in the X Window System environ- 
ment 

Fig. 1 shows the family tree for widgets in relation to the different 
versions of the Xt Intrinsics used to implement them. The Xt 
Intrinsics are the foundation upon which many user interface 
toolkits that run in the X Window System have been developed. 
The Xt Intrinsics began as the result of a collaboration between 
HP and Digital Equipment Corporation in late 1986 and early 
1987 At the end of this period, the Xt Intrinsics were contributed 
to the X Consortium * The X Consortium accepted the Xt Intrinsics 
as a nonexclusive standard for the creation of user interface 
toolkits for the X Window System environment. 

The first freely available set of software objects (widgets) based 
on these early intrinsics was done by Proiect Athena at Mas- 
sachusetts Institute of Technology The Athena widgets, because 
they were the first widgets and their development was not particu- 
larly profit motivated, had a few bugs and did not offer much in 
terms of functionality The Athena objects provided only buttons, 
scroll bars, editable and noneditable text, and boxes to contain 
them. Perhaps more important than the functionality, Ihe Athena 
widgets presented a basic model of interaction supported by 
the XI Intrinsics. 



HP's First Widgets 

HP's first X Window System user interface toolset was called 
x-ray. Xray was written in the C language and tailored to run in 
version 10 of the X Window System Although this was a good 
toolset by everyone s estimation, it was realized that tools built 
on a standard base such as the Xt Intrinsics would have a better 
chance of long-term success Therefore, x-ray was abandoned 
and work began on the HP X widgets, or as they were eventually 
called. CXI (common X interface) widgets 

HP's experience with x-ray helped to determine the feature set 
necessary for a successful user interface toolkit. Although we 
knew what we wanted to provide the customer, we were novices 
in using Xt Intrinsics. To accelerate our code production, the 
Athena widget code was used as Ihe basis for the first widgets. 

Simple widgets were created using a combination of the func- 
tionality inherited from methods in the core class widgets and 
the features provided in existing widgets. For this reason, many 
HP widgels started as a copy of an existing simple widget (ihe 
Athena label widget and the CXI button widget were the most 
commonly used). The core class methods were then modified 
until the desired change in functionality was achieved 

For more complicated widgets, two approaches were used. 
Either a simple widget was repeatedly modified until the complex 
functionality was achieved (the title bar widget is an example of 
this), or a closely parallel Athena widgel was reworked and de- 
bugged as necessary (text and paned widgets are examples of 
this). 

The New Generation 

The key features thai differentiated the CXI widgets from the 
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Athena widgels were keyboard traversal, a configurable menu 
system, and Presentation Manager behavior Keyboard traversal 
is keyboard-only operation of the user interface without touching 
the mouse As an example, consider a property sheet or a data 
entry form that contains numerous fill-m-the-blank fields In the 
model presented by the Athena widgets, the user had to move 
the mouse every time there was a need to move to a different 
field Touch typists complained that reaching for the mouse inter- 
rupted them to such a degree that they felt the interface was 
unusable. By offering keyboard traversal, the CXI widgets pro- 
vided a way to navigate through the interface without ever having 
to leave the keyboard. 

The most significant evolutionary feature of the CXI widgels. 
certainly in terms of product strategy, is the Presentation Manager 
behavior Presentation Manager is itself a user interface that has 
evolved from Microsoft Windows and is characterized by a base 
set of graphical controls with consistent behavior. While the X 
Window System is primarily for the technical workstation market, 
much of the technical workstation market comes from users mov- 
ing from personal computers to workstations Often PC users are 
hesitant to move to technical workstations because the software 
environment appears foreign and therefore is presumed hostile 
To make the move from personal computers to workstations 
easier, programs written using the CXI widgets present the user 
with an interface that behaves very much like Presentation Man- 
ager 

A New Dimension in Widgets 

In 1988 we discovered that we needed to have a unique visual 
appearance for our widgets. This resulted in the development 
of widgets with a 3D appearance (see Fig. 2). This look was 
different enough to be considered proprietary Al this point we 
had two widget libraries: a 2D widgels library, which was contrib- 
uted to the public domain, and a 3D widget library, which was 
proprietary. The 2D version of widgets, which became known as 
Xhp widgets, provided the basis for the XT+ toolkit from AT&T 
Bell Laboratories 

Soon after the release of the CXI 3D widget library, revision 3 
of the Xt Intrinsics became available. Since there is always the 
urge to use the latest lechnology, a version of Ihe CXI widgels 
was implemented using the latest Xt Intrinsics. One of the prob- 
lems with ihe earlier version of CXI widgets was that it imposed 
ihe overhead of one window for every widget. Revision 3 of the 

• The X Consortium is a group ol companies thai have |omed together lo protnole 
standards and enhancements lor the X Window System technology 



Xt Intrinsics removed this problem by providing the ability to 
support windowless objects. 

Open Standards 

With the formation of the Open Software Foundation (see box 
on page 8), the role of CXI widgets took on a whole new meaning 
In mid-1988 Ihe newly formed Open Software Foundation re- 
quested members from the entire computer industry to submit 
proposals for a technology for creating an OSF user interface 
environment. After this industry-wide solicitation and review pro- 
cess, Ihe OSF chose a hybrid of two proposals, both based on 
widget technology HP was contracted to do the engineering 
work required to create this hybrid, the OSF/Motif widget set. 

The OSF/Motif widget set is a combination of widget technology 
from HP's CXI and Digital Equipment Corporation's XUI. This 
hybrid provides the look and feel of CXI and the application 
programmer's interface of XUI. In late summer of 1989, version 
1.0 of the OSF/Motif widget library was made available. All of 
the external features of the CXI widgets were improved upon 
and incorporated into the OSF/Motif widgets. The three-dimen- 
sional visual interaction clues were extended and made more 
consistent. Keyboard traversal was extended uniformly through- 
out the widget set and made almost entirely consistent with Pres- 
entation Manager All other graphical controls such as menus 
and scroll bars were also made consistent with Presentation 
Manager behavior. 

One of the most significant contributions XUI made to the OSF/ 
Motif widget set was the addition of a rich dialog layer XUI 
presents a large number of standard dialog boxes with a number 
of standard behaviors These dialog boxes have been made 
visually consistent with CXI and behaviorally consistent with Pres- 
entation Manager. 

A Process, Not a Result 

OSF/Molif 1 0 is currently Ihe top of the evolutionary chain for 
OSF/Motif widgets. However, the evolution of technology is much 
more a process than a result Changes to the OSF/Motif widget 
set are already underway with the development of even better 
user interface components. More important, changes in the in- 
dustry customer base and advances in such technologies as 
graphics hardware, object-oriented programming, cooperative 
work, and distributed networking will continue to change the 
environment of the software industry and to provide a fertile soil 
for widget evolution 
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can inherit resources from higher-class widgets. Resource 
simply means a data name or variable whose value affects 
some attribute of the widget. For example, there are re- 
sources that control the size, color, and behavior of widgets. 
Most widgets are visible in the form of a window. Examples 
of widgets include various types of buttons, scroll bars, 
menus, and dialog boxes through which information is 
exchanged. Some widgets cannot be made visible and are 
used as supporting superclasses. These widgets supply 
common resources for the other widgets. 

Fig. 2 shows how widgets are combined to produce a 
window. The program output consists of a bulletin board 
widget and a pushbutton widget. The program that pro- 
duces this output is described later. The top-level shell 
widget is an invisible widget that provides resources and 
communicates with the X server. 1 The frame around the 
visible output is provided by the OSF/Motif window man- 
ager and is not a part of the widget system. 

A widget is composed of procedures and data structures 
that make use of the Xlib and Xt Intrinsics functions. The 
functionality provided by the few lines of code needed to 
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Fig. 3. Basic widget hierarchy 



create a widget on the screen can only be duplicated with 
many lines of code using Xlib and Xt Intrinsics functions. 
While widgets save coding time and make a program much 
easier to read and comprehend, the trade-off is that a widget 
program uses a lot more memory than an Xlib program. 
The program presented in this article uses nearly 680K 
bytes for the executable widget version and 140K bytes for 
the executable Xlib version. 

Widget Hierarchy 

The X toolkit defines widgets. To do so, it uses an object- 
based architecture that groups widgets into different class- 
es. Each widget class has data structures and procedures 
(methods) that operate on the data. Widgets also define 
what data can be imported and exported to the application 
and what actions the widget supports. This set of data is 
referred to as the resources of the widget class. A widget 
is always an instance of some class. A pushbutton is a good 
example of a widget class that defines resources common 
to all pushbuttons. This class (XmPushButton) defines the 
methods for manipulating pushbuttons (e.g., resizing), and 
the set of data that can be imported and exported from any 
instance of the class. For example, the pushbutton class 
defines a resource called armCoior. This resource controls 
the background color of the pushbutton when it is armed. 
This color can be modified in an instance of the pushbutton 
widget class by manipulating the state of the background 
resource of the affected widget instance. 

The pushbutton widget class also defines the actions that 
pushbuttons support. Instances of the pushbutton class 
have three distinct states: armed, activated, and disarmed. 
By default a pushbutton is armed when the pointer is with- 
in the pushbutton area and mouse button 1 is pressed. A 
pushbutton is activated by first arming the pushbutton and 
then releasing the mouse button while the pointer is within 
the armed pushbutton area. After the mouse button is re- 
leased, the pushbutton is disarmed. All of these behaviors 
are defined as part of the pushbutton widge! class defini- 
tion. 

Any widget class can inherit some or all of the resources 
of another class. For example, the pushbutton class con- 
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tains resources belonging to the XmLabel. XmPrimitive, and 
Core classes, as well as its own resources. Fig. 3 shows the 
relationships among the basic widget classes. Label and 
pushbutton are primitive widgets. There are other primitive 
widgets besides label and pushbutton but they are omitted 
from Fig. 3 for clarity. 

The basin widget class is the Core class. It contains re- 
sources that are inherited by all other classes. Each lower 
class can inherit some or all of the resources belonging to 
a higher class. The resources belonging to a given widget 
class can be determined by examining its man page in the 
HP OSF/Motif Programmer's Reference Manual. 

A Widget Program 

The following program illustrates the use of widgets in 
a program. The program consists of a pushbutton widget 
that is contained in a bulletin board widget. Selecting the 
pushbutton causes a message to be displayed on the termi- 
nal window and then the program terminates. The program 
is called xmbutton.c and the output from the program is 
shown in Fig. 4. 

/•• 

lile: xmbutton.c 

project: Motif Widgets example programs 

description; This program creates a PushButton widget. 

E Copyright 1989 by Open Software Foundation. 
Inc. All Rights Reserved. 

E Copyright 1989 by Hewlett-Packard Company. 
••• •/ 

f include header files 'I 

#include <X1 1 lntrinsic.h> 
#include <Xm/Xm.h> 
#mclude <Xm,BulletinB.h> 
#include <Xm PushB.h> 

functions defined in this program V 

void main(); 

void activateCBO; * Callback for the PushButton */ 
'* global variables "/ 

char "btnjext; f button label pointer for compound string 



main - main logic for xmbutton.c program 

• 

void main (argcargv) 
unsigned int argc: 
char "argv; 

f 

Widget toplevel; f* Shell widget 



Widget bboard, "BulletinBoard widget 

Widget button; /"PushButton widget 

Arg args[10); /'arglist 7 

register Intn; /'arg count "/ 



initialize the Xt Intrinsics */ 
toplevel = Xtlnitialize 

("main", "XMburton", NULL. NULL. &argc. argv); 

Create a bulletin board widget in which the pushbutton widget "/ 
F can be placed 7 

n = 0; 

bboard = XmCreateBulletinBoard (toplevel, "bboard", 
args, n); 

Manage the bulletin board widget V 
XtManageChild (bboard); 
" Create a compound string for the button text 7 
btnjext = XmStringCreateLtoR 
("Push Here". XmSTRING_DEFAULT_CHARSET); 

f set up arglist V 

n = 0; 

XtSetArg (args[n). XmNlabelType. XmSTRING); n+ + ; 
XtSetArg (argsln), XmNlabelString, btnjext); n+ + ; 
create button "/ 

button = XtCreateManagedWidget 
("button", xmPushButtonWidgetClass.bboard, args, n); 
add callback 7 

XtAddCallback (button, XmNactivateCallback, activateCB, 
NULL); 
realize widgets '/ 
XtRealizeWidget (toplevel); 
P process events 7 
XtMainLoop (); 

I 

/• 

activateCB - callback for button 

void activateCB (w. clienLdata, calLdata) 

Widget w; F widget id 7 

caddrj clienLdata ; f data from application 

caddr J calLdata: F data from widget class 

I 

F print message, free compound string memory, and terminate 
program V 

prinrf ("PushButton selected. n"); 

XtFree(btnjext); 

exit (0); 

I 

There are nine steps in writing widget programs. These 
steps are used regardless of the complexity of the program. 
The nine steps are: 

1. Include the required header files. 

2. Initialize the Xt intrinsics. 

3. Add additional top-level windows, if needed. 

4. Create argument lists for the widget. 

5. Create the widget. 

6. Add callback procedures. 

7. Realize the widgets and loop. 

8. Compile and link the program. 

9. Creale the defaults files. 
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Fig. 4. Output from the program xmbutton 



Steps 4 through 6 are done for each widget included in 
the program. The next nine sections relate these steps to 
the program xmbutton. c. 

Include Required Header Files 

Some common variables and types of variables used by 
the widgets are defined in header files. The necessary 
header files are included at the beginning of the program. 
These header files are: 

#include <stdio.h> 
#include &<X11/lntrinsic.h> 
#include &<Xm/Xm.h> 
#include &■ Xm widget> 

Replace widget wilh the name of the corresponding widget 
header file for each widget class used in the program. The 
include files for all widgets are found in the directory /usr'in- 
clude/Xm. The header file name for each widget can be found 
in the synopsis section of each widget's man page. The 
order in which header files are placed is very important. 
This order must be: 

■ General header files, such <stdio.h> 

■ Xt Intrinsics header files, such as <X11'lntrinsic.h> 

■ Widget header files, beginning wilh <Xm.h> and includ- 
ing a header file for each widget class used in the pro- 
gram. The order within the widget header files is not 
critical. 

For xmbutton. c. the include files are: 

^include • Xl1/lntrinsic.h> 
#include < Xm/Xm.h> 
#include ■ Xm/BulletinB h 
#include « Xm PushB.h^- 

Note that there is an include file for the bulletin board 
widget and one for the pushbutton widget. 

Initialize the Xt Intrinsics 

The Xt Intrinsics must be initialized before any other 
calls are made to Xt Intrinsics functions. The most conve- 
nient method of accomplishing this is to use the function 
Xtlnitialize. This function establishes the connection to the 
X server, parses the command line that invoked the appli- 
cation, loads the resource data base, and creates a shell 



widget that will serve as the parent (or top level) widget 
for the application widgets. The call to Xtlnitialize in xmbutton. c 

is: 

toplevel = Xtlnitialize ( main' . XMbutton ", NULL. NULL. Sargcargv). 

The first two parameters, main and "XMbutton ", are used 
to reference defaults files, which are ASCII files used by 
the system to set the values of widget resources. Defaults 
files are explained in more detail later in this article. The 
next two parameters are set to NULL since they are not used 
in this example. The last two parameters. &argc and argv. 
are the number of command-line parameters and the array 
in which they are stored. 

The syntax for Xtlnitialize is: 

Xtlnitialize (shelLname. app_class, options. num_options, argc. argvl 

Type Parameter 

String shelLname. 

String app-class; 

XrmOptionDescRec options! ]; 

Cardinal num_options; 

Cardinal "argc: 

String argv[ ]; 

where: 

■ shelLname specifies the name of the application shell 
widget instance. 

■ app_class specifies the class name of this application. 

■ options specifies how to parse the command line for any 
application-specific resources. 

■ num_options specifies the number of entries in the options 
list. 

■ argc specifies a pointer to the number of command line 
parameters. 

■ argv specifies the address of the command line parame- 
ters. 

Adding Additional Top-Level Windows 

Xtlnitialize can be executed only once in any program, so 
to create additional lop-level widgets the functions 
XtCreateApplicationShell or XtAppCreateShell must be used, 
XtAppCreateShell allows the creation of a user-defined display 
while XtCreateApplicationShell uses the default display. 
XtCreateApplicationShell is from an earlier version of X, so it 
is probably better to use XtAppCreateShell. Xmbutton. c does not 
use a second top-level shell so neither of Ihese functions 
appears in the program. 

Creating Argument Lists and Widgets 

The next step in the program is to create widgets. In most 
cases this involves setting widget resource name-value 
pairs into an argument list and then calling a create function 
for the widget. A name-value pair is a resource name and 
the value assigned lo that resource. For example, the re- 
source name labelString might have a string value "ABCD" 
assigned to it. 

There are two methods to create widgets. The first 
method involves using convenience functions, and the sec- 
ond method involves using generic Xt Intrinsics. Conve- 
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nience functions, which are part of the widget library, are 
used to create a specific type of widget. For example, 
XmCreateBulletinBoard creates an instance of a bulletin board 
widget and XmCreatePushButton creates an instance of a 
pushbutton widget. Widgets created with Xt Intrinsics are 
automatically managed when they are created. However, 
widgets created with a convenience function must be man- 
aged with the function XtManageChild or XtManageChildren. 
Managing widgets this way provides some flexibility and 
saves time because a number of widgets can be created and 
managed all at once. 

Using Convenience Functions. In the program xmbutton.c.the 
convenience function XmCreateBulletinBoard is used in the 
following lines of code to create a bulletin board widget. 

/' Create a bulletin board widget in which the pushbutton 

/* widget can be placed */ 

n = 0; 

bboard = XmCreateBulletinBoard(toplevel, 
"bboard", args.n), 
Manage the bulletin board widget 
XtManageChtld(bboard); 

The variable n. which is used here to specify the number 
of name-value pairs in the argument list, is zero, indicating 
that there are no name-value pairs in the argument list. 
The function XtManageChild is used to manage the bulletin 
board widget bboard. 

The syntax for XmCreateBulletinBoard is: 

Widget = XmCreateBulletinBoard (parent, name, args, num_args) 



Type 

Widget 
String 
Arglist 
Cardinal 



Parameters 

parent; 
name; 
args; 

num_args; 



where: 

■ parent specifies the parent widget of the newly created 
widget (toplevel in this example). 

■ name specifies the resource name for the created widget 
(bboard in this example). This name is used for retrieving 
resources and should not be the same as any other widget 
that is a child of the same parent. 

■ args specifies the argument list for resource values. 

■ num_args specifies the number of arguments in args. 
The syntax for XtManageChild is: 

XtManageChild (child); 



Type 

widget 



Parameter 

child 



where the parameter child specifies the widget to be man- 
aged. 

Using Xt Intrinsics. The pushbutton widget in xmbutton.c is 
created using the Xt Intrinsic XtCreateManagedWidget. The 
lines of code associated with creating the pushbutton 
widget are as follows. 



r Create a compound string for the burton text 7 

btnjext = XmStringCreateLtoP. 

('Push Here ", XmSTRING_DEFAULT_CHARSET); 
P set up arglist 7 

n = 0: 

XSetArg(args[n), XmNlabelType. XmSTRING);n + + ; 
XSetArg(args[n), XmNlabelString, btnjext); n + + ; 
create button 7 
button = XtCreateManagedWidget 
("button", xmPushButtonWidgetClass, bboard, args.n); 

The call to the widget library function XmStringCreate has 
nothing to do with creating a widget, but it does set up a 
compound string for the pushbutton label. A compound 
string is designed to allow any text to be displayed without 
having to resort to hard coding certain language dependent 
attributes. The variable btnjext is a pointer for the com- 
pound string "Push Here." 

The Xt Intrinsic function XtSetArg is used to set up the 
argument list. It sets the the values for specified widget 
resources into an array that is subsequently accessed by 
the widget when it is created. The syntax for XtSetArg is: 

XtSetArg (arg, name, value) 



Type 

Arg 

String 

XtArgVal 



Parameters 

arg; 

name; 

value; 



where: 

■ arg specifies the name-value pair to be set. 

■ name specifies the name of the resource. 

■ value specifies whether the value of the resource will fit 
in a long integer (XtArgVal is defined to be of type long int 
in an Xt Intrinsics header file): otherwise, it specifies 
the address. 

The intrinsic XtCreateManagedWidget creates a pushbutton 
widget that has the name button and the bulletin board 
widget bboard as its parent. Note that creating a widget 
merely creates the data structures associated with that 
widget. It does not make the widget visible on the screen. 

The syntax for XtCreateManagedWidget is: 

Widget ■ XtCreateManagedWidget (name. widgeLclass, parent, args, 

num_args) 



Type 

String 

WidgetClass 
Widget 
ArgList 
Cardinal 



Parameters 

name; 

widgeLclass; 

parent; 

args; 

nurruargs; 



The parameters name, parent, args. and num_args specify 
the same values as their counterparts in the convenience 
function XmCreateBulletinBoard. The parameter widgeLclass, 
which is of type WidgetClass, specifies the widget class 
pointer for the created widget. 
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Adding Callback Procedures 

Callbacks are procedures that are executed when certain 
events occur within a widget. Events such as pressing a 
mouse button, pressing a certain key on the keyboard, or 
moving the cursor into or out of a window can trigger a 
callback procedure. Every widget has a callback list for 
each type of callback it supports. This list contains the 
callback procedures to be executed when a particular event 
occurs. For example, every widget supports an XtNdestroy- 
Cailback list. Each callback procedure in this list is executed 
before the widget is destroyed. Information on the callbacks 
supported by a given widget can be found in the man page 
for that widget and any supporting superclass widget that 
supplies resources to it. There are two steps involved in 
adding a callback procedure: writing the callback proce- 
dure and add i ng the callback procedure to the callback list. 
Writing a Callback Procedure. A callback procedure re- 
turns no value and has three arguments: 

■ The widget for which the callback is applicable. 

I Data passed to the callback procedure by the application. 

■ Data passed to the callback procedure by the widget. 
In xmbutton.c, the callback procedure activateCB prints a 

message to the standard output (this is normally the termi- 
nal window from which the application was executed), 
frees the memory used by the compound string stored in 
the variable btnjext, and ends the program by executing the 
system exit procedure. The callback procedure is just like 
any routine or procedure except that it is called only when 
the event to which it is tied occurs. In xmbutton.c, the activate- 
CB callback procedure is executed when mouse button 1 
is pressed and released and the mouse pointer is located 
within the pushbutton window. It is the release of the 
button (an event known as BtmUp) that causes the pushbut- 
ton to be activated and the callback procedure to be exe- 
cuted. 

Adding the Callback Procedure to the Callback List. The 

callback procedure is added to a specific callback list that 
is owned by the widget. This is done by using the Xt Intrin- 
sics function XtAddCailback. In xmbutton.c the callback proce- 
dure is added with the code segment: 

*" add callback "/ 

XtAddCailback (button, XmNactivateCallback, activateCB, NULL); 

The syntax for XtAddCailback is: 

XtAddCailback (w. callbackjist, callback, clienLdata) 



Type 

widget 
String 

XtCallbackProc 
caddrj 



Parameters 

w; 

callbackjist; 

callback; 

clienLdata; 



where: 

■ w specifies the name of the widget to which the callback 
procedure is to be added. 

■ callbackjist specifies the callback list within the widget 
to which the callback procedure is to be added. 

■ callback specifies the name of the callback procedure to 
be added. 



» clienLdata specifies the client data to be passed to the 
callback when it is executed. 

Note that the callback is added after the widget has been 
created with XtCreateManagedWidget. This is necessary be- 
cause one of the parameters for XtAddCailback is the pushbut- 
ton widget known as button. An error would occur if a 
callback is added to a widget that does not exist. 

Making the Widget Visible 

Even though we have created a widget and added a 
callback procedure to one of its callback lists, if we were 
to compile and execute the program at this point, nothing 
would be visible on the screen. This is because we have 
not passed the essential information about our widgets to 
the Xt Intrinsics functions that actually display the widgets 
on the screen. This is accomplished by using the function 
XtRealizeWidget. 

The final step in the program is the call to the Xt Intrinsics 
XtMamLoop. XtMainLoop is really an event loop. As events 
occur, this function dispatches them and then searches or 
waits for the next event to occur. In our simple example, 
only the one event BtmUp has any meaning. The window 
shown in Fig. 4 will remain displayed indefinitely until 
the pushbutton is pressed by moving the mouse pointer 
into the button window and pressing and releasing mouse 
button 1. 

In the program xmbutton.c, displaying the widget and loop- 
ing are performed in the code segment: 

r realize widgets 'I 

XtRealizeWidget (toplevel); 
f process events */ 

XtMamLoop (); 

Notice that there is no exit in the main part of the pro- 
gram. Program termination is taken care of in the callback 
procedure activateCB. 

Compiling and Linking 

For compiling and linking the program xmbutton, one of 
the following command lines is used. 

■ For HP 9000 Series 300 computers use: 

cc -O -Wc, -Nd4000 -Wc, -NS4000 -Wc, -N15000 -DSYSV -o\ 
xmbutton xmbutton.c -IXm -IXt -1X11 

■ For HP 9000 Series 800 computers use: 

cc -0 -DSYSV -o xmbutton xmbutton.c -IXm -IXt -1X11 
The libraries Xm. Xt. and X1 1 . which are linked into the 
program, must appear in the order shown. Xm is the widget 
library, Xt is the intrinsics library, and X11 is the Xlib func- 
tions. 

Creating Defaults Files 

In the example above, the values of certain widget re- 
sources have been set by means of argument lists within 
the program. Anolher method of setting resource values is 
by means of ASCII files called defaults files. These files 
are automatically read by the system before executing a 
program. There are two types of defaults files: an app-default 
file and a user-specific file called Xdetauits. 
App-Default File. This file is located in the directory usr lib 
X11/app-defaults and supplies defaults for an entire class of 
applications. The class is specified in the call to Xtlnitialize. 
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For example, the call to Xilnitialize in xmbutton.c specifies the 
application class XMbutton (hy convention, application class 
names are the program name with the first two letters 
capitalized). The app-defaults file XMbutton contains resource 
values for certain widgets that are used in the program 
xmbutton.c. An example of such a file is shown below. 

! XMbutton app-defaults lile for Motif demo program xmbutton.c 
I general appearance and behavior defaults 



•fontList: 

"shadowThickness 

I 

! BullelinBoard resources 

| 

■bboard. resizePolicy : 
'bboard.height: 
"bboard. width: 
"bboard. background: 



! PushButton resources 

I 

"button. foreground: 
'button background: 
"button. borderWidth: 
"button. height: 
'button. width 
'button x: 
"button.y: 
I 



hp8.8* 16b 
3 



RESIZE.NONE 

150 

250 

sky blue 



midnight blue 

goldenrod 

0 

30 

100 

75 

60 



Xtlnitialize uses the data contained in XMbutton to build a 
resource data base before the widget is actually created. 
.Xdefaults File. This file can be created in each user's home 
directory to set resource values for any number of programs. 
Defaults found in this file override those in an app-default 
file and allow different users to specify different values for 
the same resources. For example, one user may prefer to 
have different background and foreground colors from the 
ones set in the app-default file. Note that the values in the 

Xdefaults file only override the app-defaull values. They do 
not change them. Suppose you want to override the default 
background and foreground colors for both the bulletin 
board widget and the pushbutton widget in xmbutton.c. The 

Xdefaults file shown below changes the background of the 
bulletin board to white, the background of the pushbutton 
to red, and the foreground of the pushbutton to white. Note 
that the colors are only changed for the program xmbutton. 

xmbutton'button. foreground: white 
xmbutton'button. background: red 
xmbutton'bboard. background: white 

The colors can be changed so that the background and 
foreground colors are the same for every widget in xmbutton 
with this Xdefaults file: 

xmbutton.foreground: white 
xmbutton background: red 



The order of precedence for setting values in widget re- 
sources is: 

■ The app-defaults files 

■ The Xdefaults file 

■ The values that are set in the program. 

This means that values set in an app-default file can be 
overridden by an Xdefaults file and values set in an Xdefaults 
file can be overridden by values set in the program. 

An Equivalent Xlib Program 

A program using Xlib and Xt Intrinsics functions rather 
than widgets to produce our pushbutton and bulletin board 
combination would take nearly four pages of code. For this 
reason, only a portion of the equivalent Xlib program is 
presented here. 

The previous section discussed defaults files as a means 
of setting the value of a widget's resources. If widgets are 
not used then defaults files cannot be used. For example, 
in xmbutton.c we used a single line in an .Xdefaults file to set 
the background color of the pushbutton widget: 

Button. background: goldenrod 

Similar entries were made in the defaults files to set 
values for other resources. Without widgets, setting up re- 
source values requires several lines of code in the applica- 
tion program. For example, to set the background color in 
an Xlib program, the color must first be allocated and then 
used as one of the arguments to the function XCreate- 
SimpleWindow. The following code segment shows what this 
involves: 

#include<Xl1/Xlib.h> 
#include<X11'Xutil.h> 
#include<stdio.h> 

#defineOFF0 
#defineON1 

#define FALSE 0 
#defineTRUE1 

Display "dpy; 

Window parent, child, root; 
GC shadow_gc, texLgc: 

unsigned long sky_blue, ILblue, goldenrod. wheat, dk_grey, 

white, black; 

int screen; 

XFontStrucffptr: 

Colormapcmap: 

main(argc, argv) 
intargc; 
char "argvfj; 

1 

XColor hard_def. exact_def; 
XSizeHints xsh; 
XEvent event: 

int state - OFF. tx. ty. status, pressed = FALSE: 
"Open the display' 

if ((dpy = XOpenDisplay(NULL)) = NULL) ( 
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fpnntf(stderr. %s: Cannot open DISPLAYn . argviO]); 
exit(1): 

I 

' Set parameter values * 

screen = DefauKScreen(dpy); 

root = FtootWindowldpy, screen); 

cmap = DefaultColormapldpy. screen): 

white = WhitePixeKdpy .screen); 

black = BlackPixelldpy screen): 
" Create graphics contexts " 

text_gc m XCreateGC(dpy, root, 0.0): 
shadow_gc = XCreateGC(dpy, root. 0.0); 
'Allocate colors' 

status - XAIIocNamedColor(dpy, cmap. "SkyBlue", 
&hard_def, &exact_def); if (Istatus) ( 
fprinrl(stderr, "%s: Cannot allocate the neccessary colorsn", 
argv[0]);exit(1); 

I 

else 

sky_blue = hard_def.pixel; 
status = XAIIocNamedColor(dpy,cmap,"LightBlue". 

&hard_def, &exact_def). if ( status) \ 
fprintf (stderr, "%s: Cannot allocate the neccessary colorsn", 
argv[0j);exit(1), 
I 

else 



lt_blue = hard_def.pixel; 
"Load font" 

fptr = XLoadQueryFontidpy, hp8.8x16b"); 
if (fptr = = NULL) { 

fprintf(stderr, -%s Cannot load the neccessary fontn . argvfO)); 
exrt(1); 
I 

XSetFont(dpy,text^c.fptr->fid); 
' Geometry calculations ' 

ty = (30-fptr->ascent-fptr- --descent) 2 - fptr-. -ascent; 
tx = (100-XTexlWktm(tptr, Push Here ,9))/2; 

xsh.x = 0;xsh.width = 250: 
xsh.y = 0;xsh. height = 150; 
r Create bulletin board equivalent ' 

parent - XCreateSimpleWindow(dpy, root, xsh.x, xsh.x, xsh. width, 

xsh.height, 2. iLblue, sky .blue); 



} 

Although there is more to this code than just allocating 
colors, it is obvious that there is a lot more involved than 
is required when using widgets. 
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The HP SoftBench Environment: An 
Architecture for a New Generation of 
Software Tools 

The HP SoftBench product improves programmer 
productivity by integrating software development tools into 
a single unified environment, allowing the program 
developer to concentrate on tasks rather than tools. 

by Martin R. Cagan 



THE HP SOFTBENCH PRODUCT is an integrated soft- 
ware development environment designed to facili- 
tate rapid, interactive program construction, test, and 
maintenance in a distributed computing environment. 

The HP SoftBench environment provides an architecture 
for integrating various CASE (computer-aided software en- 
gineering) tools. Many of the tools most often needed — pro- 
gram editor, static analyzer, program debugger, program 
builder, and mail — are included in the HP SoftBench prod- 
uct. Another HP SoftBench component, the HP Encap- 
sulator, makes it possible to integrate other existing tools 
into the HP SoftBench environment and to tailor the envi- 
ronment to a specific software development process. Fig, 



1 illustrates the HP SoftBench user interface. 

This article describes the HP SoftBench tool integration 
architecture. The HP SoftBench program editor, static 
analyzer, program debugger, program builder, and mail are 
described in the article on page 48. The HP Encapsulator 
is described in the article on page 59. 

Design Objectives 

The overall goal of the HP SoftBench product is to im- 
prove the productivity of programmers doing software de- 
velopment, testing, and maintenance. To achieve this goal, 
the following objectives were defined for the tool integra- 
tion architecture: 

(continued on page 38) 
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Fig. 1 . Typical HP SoftBench user 
interface. 



36 HEWLETT-PACKARD JOURNAL JUNE 1990 



© Copr. 1949-1998 Hewlett-Packard Co. 



Architectural Support for Automated Testing 



The importance of software testing does not have to be argued 
anymore ' There also exists a relative wealth of sources describ- 
ing various aspects of software testing Unfortunately, most of 
the published literature concentrates on elegant approaches to 
limited subproblems derived from traditional software (that is 
batch-oriented input/output). Additionally, the published body of 
knowledge almost completely ignores the issue of how the testing 
activity should fit modern project life cycles (reference 2 is a rare 
exception) 

This section is about testing a large software system the HP 
SoftBench product described in the accompanying article. The 
goal is to describe both the process and the various tools and 
utilities developed to exploit the architectural advances of the 
HP SoftBench product to support the testing process 

The problem of testing a system such as the HP SoftBench 
environment is difficult and therefore interesting. The problem 
has the following major attributes: 

■ Development of the HP SoftBench system followed the spiral 
life cycle 3 which, because of its crucial aspect of rapid pro- 
totyping, presents a real challenge for formal testing. 

■ The formal testing activity started early in the proiect life cycle 
and closely tracked the project development. 

■ The system being tested consists of several tightly integrated 
tools and is event-driven 

■ The system has a sophisticated user interface (window-based 
and mouse-driven). 

■ Black-box tests had to be automated (which in ihe case of 
the user interface meant developing an "automatic user"). 

■ The testing proceeded along an unorthodox path — from black- 
box testing, through "grey-box testing" (driven by branch flow 
and complexity analysis), to white-box testing 

Automatic Regression Testing 

Traditional testing methods focus on exercising and testing 
programs by stimulating them using controlled inputs and ob- 
serving their outputs If the input and output sets are "well-be- 
haved" (e.g., numeric values) then it may be possible to prune 
the test space using the techniques of equivalence partitioning 
or boundary analysis." 

The HP SoftBench product presents a special challenge. Its 
user interface is almosl completely mouse-driven and makes 
heavy use of hierarchically arranged windows. The system inte- 
grates actions of several tools through a message interface. The 
output is mostly visual Finally, the system can run in a distributed 
environment on many processing units and varying displays. 

Automatic testing of such a system implies the need for a 
"robot tester," blindfolded and handcuffed but capable of enter- 
ing input and verifying output One possibility is to operate at 
the pixel level and generate required actions (pushing buttons, 
etc) at specific points on a screen The verification of output 
would then require taking screen snapshots and comparing them 
with the expected screens. The problem is that this approach is 
tied directly to the screen's appearance. A mere change in fonts 
or other screen attribute (e.g., color scheme) would completely 
invalidate this testing approach A higher-level approach is 
needed 

An HP SoftBench tool has two mapr interfaces: the user inter- 
face (mouse/keyboard/window) and the message interface We 
used both interfaces to exercise and verify HP SoftBench be- 
havior. To deal with Ihe user interface challenge, we used two 
mechanisms thai allowed us to stimulate inputs and register out- 



puts independently of screen parameters On the input side we 
identified inputs (buttons to be pushed or editing windows) not 
by their screen coordinates but by symbolic names associated 
with these objects Thus, the automatic testing tools are able to 
find some wirxJow9 no matter where that window is placed on the 
screen (or even if it is completely obstructed by other windows) 
To obtain higher-level verification of outputs without resorting to 
pixel-level screen dumps, we instrumented the code so that any 
window could be probed and forced to dump its contents (strings 
or a pointer position in the case of the edit widget, or a label in 
the case of a button) This approach allows selective probing of 
software objects (very much like having testing probes in 
hardware). 

Testing Tools 

Two companion testing tools were used to drive both HP 
SoftBench interfaces — user and message Tool A allows the tester 
to send messages to the message server It can intercept mes- 
sages and match them against a list of expected messages. 
Tool A can also act on widgets Tool A's companion utility tool 
B, is capable of automatically and interactively creating a test 
file that mixes message and widget operations. This file becomes 
the input to tool A. 

Tool A allows the user to send messages to the message 
server. Tool A will then wait for the tools to respond to the mes- 
sages The order in which the messages are sent and received 
is restricted by a partial order relation given by the user. This 
ordering can be totally unrestricted, strictly sequential, or any- 
thing in between 

Tool A maintains an active list of commands as it runs a test 
As each command is executed it is removed from the active list 
and all of its successors are checked to see if they should be 
added to the active list A command is not added to the active 
list until all of its predecessors have been executed. 

Actions and Software Probes 

Tool B can be used to log two types of events. It can intercept 
messages and it can also log operations on widgets into a test 
file. All of the widget-based commands search X11'S window 
tree for the named widget at the time the command is executed. 
The search is done at this time because windows are constantly 
being created, destroyed, and moved aboul wilhin the tree. The 
search algorithm does a breadth-first search of the window tree 
for the first name of the widget. As each match is encountered 
a second breadth-first search is started on the subtree of the 
matched window, looking for the second name of the widget 
These searches continue until the tree is exhausted or all of the 
names of the widget are found. The search algorithm remembers 
that it has touched a particular application, and as a result all 
the subsequent widget searches use that shortcut (resulting in 
about a 90% speed-up m the search lime) 

When capturing tests with tool B. the tester can identify a 
widget that needs to be probed at the test time The information 
dumped for a widget includes all text seen on the display, whether 
the text is sensitive (grayed out), and whether it is set or marked 
(only for menu buttons and toggles) This scheme allows us not 
only lo describe the events to execute the actions, but also to 
specify what needs to be checked to verify that the actions hap- 
pened correctly. 

(continued on ne«l page] 
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Supporting Utilities 

Our tests were stored in the HP-UX revision control system 
(res) and ran in the proprietary HP Scaffold testing harness. 5 We 
used branch flow analysis (BFA) to monitor the coverage of the 
code and to steer the testing activities. 6 We combined the BFA 
information (annotated source code) and the results of the com- 
plexity analysis (McCabe's ACT 7 ) to focus on testing the areas 
ol the code that have high complexity and low BFA coverage 
(grey-box testing). 
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■ Support integrated tool sets. The tools should cooperate 
to present a task-oriented environment that lets users 
concentrate on what they want to do, not how to do it. 

■ Support interchangeable tools. HP's CASE strategy is 
based on the belief that there is no single solution appro- 
priate for all users. The type of application being de- 
veloped, the size of the team, the delivery constraints, 
and the development methodology all impact the opti- 
mal tool set. The integration architecture should permit 
any tool to be replaced such that no changes need to be 
made to the other tools and the new tools cooperate with 
the other tools in the environment at least as well as the 
original tools do. 

■ Support a distributed computing environment. The ar- 
chitecture needs to support software development in a 
distributed computing environment composed of combi- 
nations of X terminals, workstations, midrange comput- 
ers, and servers, possibly in geographically dispersed 
locations. Tool execution, data, and display should all 
be designed for a network environment. 

■ Leverage existing tools. Users need to be able to integrate 
tools they already use, which they have either purchased 
or developed, into their software development environ- 
ment. To do so, they should not have to modify the 
source code of any tool or change the other tools in the 
environment. 

■ Support software development teams. The tools and ar- 
chitecture should support team coordination and the 
management of project files in a distributed development 
environment. 

■ Support multiple work styles. The HP SoftBench product 
should not dictate a single style of work. The style should 
be based on the task. For example, if the user is primarily 
doing maintenance the environment should be centered 
around the maintenance task, and if the user is primarily 
doing rapid prototyping, the environment should be cen- 
tered around the program construction task. 

■ Support other life cycle tools. The HP SoftBench ar- 
chitecture should facilitate the integration of additional 
life cycle tools such as project management, documenta- 
tion, analysis, and design tools. 

■ Build on standards. The HP SoftBench architecture 
should build on the UNIX* operating system, NFS and 

UNIX is a registered trademark of AT&T in the U S.A and other countries 



ARPA networking, the X Window System'" Version 11, 
and the OSF/Motif appearance and behavior. 

Architecture Overview 

We define a software engineering environment to be an 
ensemble of tools thai collaborate to support the user's 
software engineering process. 1 There are several types of 
tool integration. The HP SoftBench tool integration ar- 
chitecture concentrates on providing mechanisms that sup- 
port tool collaboration in a distributed computing environ- 
ment. This type of integration is often called control inte- 
gration or process integration. 

The architectural facilities provided by the HP SoftBench 
product are complementary to those in other integration 
architectures that concentrate on providing services for 
sharing data between tools and managing data relation- 
ships. 2 - 3 ' 4 

Over the last several years, university and industrial re- 
search laboratories have been addressing the issues of im- 
proved software tool integration facilities. z ' 5 ' h ' 7 The HP 
SoftBench tool integration services are an implementation 
of much of Ihis research in a commercial product. There 
are three primary components in the HP SoftBench tool 
integration architecture: 

■ Tool communication 

■ Distributed support 

■ User interface management. 

Tool Communication 

HP SoftBench tools communicate in a networked envi- 
ronment via a broadcast communication facility designed 
to support close communication of independent tools. 

In the UNIX operating system, tool communication is 
typically limited to single-direction, point-to-point data 
streams (pipes). In the HP SoftBench environment, tool 
communication is two-way, one-to-many or many-to-one, 
and event-driven. 

Message-Based Application Program Interface 

All HP SoftBench tools, as well as nonSoftBench tools 
that have been properly integrated using the HP Encap- 

X Window System is a trademark of the Massachusetts Institute of Technology 
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Broadcast Message Server Message Structure 



HP SofiBench tools communicate by sending messages, which 
ate dispatched Dy the broadcast message server (BMS) to 
appropriate other tools HP SoftBench messages have the follow- 
ing structure 

Ongmato' Request-id Message-Type Command-Class 
Command-Name Context [Arguments] 

Originator. The originator is the tool that sent the message How- 
ever, by convention, this field is not usea by the HP SoftBench 
tools themselves because they do not send messages to a par- 
ticular tool; they send them to the BMS so that other tools in- 
terested in the events can be notified 

Request-td. The request ID is constructed from the triple (message- 
number, process-id. host) This network-wide unique ID is used so 
that responses can be associated with their original requests In 
other words, a notification sent as the result of a request has the 
same request ID as the original request to which it is responding 
Message-Type. The defined message lypes are. 

R = Request message 
N = Success notification 
F = Failure notification 



Command-Class. The command class is the type of operation (e g . 

EDIT DEBUG). 

Command-Name. The command name is the name of the operation 
within the command class (eg save-file step, stop) The 
combination of the command class with the command name 
defines a unique operation, (e g . edit save-file or debug step) 
Context The context is the tnple (host, base directory, file) This 
indicates the location of the data being operated on The contexl 
is used lo distinguish between multiple instances of the same 
tool For example, if the user is working on two projects at once 
and has two debuggers running, the context ensures that the 
nght messages get sent to the right debugger 
Arguments. Each message may have optional, variable-formal 
argumenl lists, which provide additional information regarqmg 
the operation — for example, the name of a function or variable 
In the HP SofiBench product, complex data is passed by refer- 
ence rather than by value For example, if the message is a 
nolification from the static analysis tool with the response to a 
request for a complex query, Ihe arguments contain a pointer to 
a file containing Ihe data. 



sulator. provide access to their functionality through a mes- 
sage-based application program interface (API). Any action 
that can be initiated through the tool's user interface can 
also be initiated through the message interface. 

When an HP SoftBench tool or an encapsulated tool 
wants to cause another tool to perform an operation, it 
sends a request message. The tool requesting the service 
does nof know the particulars of the tool that will service 
the request. It only deals in terms of an abstract tool pro- 
tocol. There are several predefined tool protocols In the 
HP SoftBench environment, one for each class of tool (e.g.. 
DEBUG, EDIT, BUILD). Each tool protocol is composed of a 

Bel oi operations (e.g., step, set-breakpoint, continue). 

As long as a new tool fully supports the appropriate tool 
protocol, that new tool can be substituted for Ihe original 
tool, and the other tools in the environment continue to 
operate with the new tool just as they did with Ihe original 
tool. With the HP Encapsulator. users can define new tool 
protocols or develop new tools for existing protocols. 

There are several important benefits of having a message- 
based interface to all tools in the environment, but the 
primary reason is for task automation. Tools can be con- 
trolled by other tools instead of a person. 

Other benefits of a message-based interface include pro- 
grammatic application testing (see "Architectural Support 
for Automated Testing," page 37), computer-based training, 
and on-line help (see "Integrated Help." page 57). The value 
of a message-based API has been demonstrated in several 
systems. Most influential in the HP SoftBench design were 
the FIELD system done at Brown University, 5 the FSD sys- 
tem done at USC-ISI. 2 and the HP NewWave environ- 
ment. 38 



Event Triggers 

An important extension to the message-based API model 
is that all HP SoftBench tools and all external tools that 
have been integrated using the HP Encapsulator announce 
the action they just took after each operation they perform. 
This notification message is sent whether the operation 
was initiated from the user interface or from the message 
interface. The notification message also indicates whether 
the operation was successful (see "Broadcast Message 
Server Message Structure," above). 

These notifications are the key to a powerful HP 
SoftBench concept known as evenl triggers. A trigger is a 
set of operations to be executed when an event occurs 
somewhere in the user's software engineering environ- 
ment. As a simple example, when an HP SoftBench tool 
modifies a file, it announces this fact, so that other tools 
that are operating on the file can be updated appropriately. 
The notion of a tool announcing its operations comes from 
the research on FIELD at Brown University. 5 

In the HP SoftBench environment, certain triggers are 
predefined in the tools. More important, users can define 
their own triggers with the HP Encapsulator, keying off 
any notification in the user's environment. For example, 
the user might define an event trigger thai automatically 
notifies the team whenever a successful build occurs, or 
metrics might be collected whenever a file is checked into 
version control. 

Broadcast Communication 

The HP SoftBench environment uses a broadcast model 
of tool communication provided by the facility known as 
the broadcast message server (BMS). The BMS is the dis- 
patcher of messages between the various tools in the user's 
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Distributed Execution, Data, and Display 



The distributed computing support capabilities of the HP 
SoftBench environment can support a variety ot machine config- 
urations. Fig 1 shows an example ot a configuration. Assume 
that an engineer has a small, inexpensive X display machine 
(possibly a diskless HP 9000 Model 340 workstation or an X 
terminal). Also assume that the HP SoftBench environment is 
installed on an HP 9000 Model 370 server machine, and that the 
engineer is developing software for an HP 9000 Series 800 
machine, which is used as a central data storage facility A typical 
HP SoftBench configuration will probably have one or two 
machines instead of the three in this example. However, it is 
possible to come up with configurations that use more machines. 

In this example, first the engineer would start the HP SoftBench 
environment on the Model 370 HP SoftBench server, with the 
DISPLAY environment variable pointing to the X display server. 
One of the features of the HP SoftBench distributed execution 
facility is thai the current environment of a process is always 
maintained when executing a child process, even over a network 
connection. Thus, if any X clients are spawned, the child X client 
will point to the correct display machine. Next, the engineer starts 
the HP SoftBench build tool, with the context set to the Series 
800 machine. Finally, the engineer selects the build tool's build 
button. The HP SoftBench subprocess control (SPC) facility will 
now do two things. It will set the working directory to match the 
context host and directory, and it will spawn a make process on 
the Series 800 machine in this working directory. Alternatively, 
the build tool can be configured to spawn the make process on 
a different, possibly less loaded machine, but the working direc- 
tory will still point to the same context directory. 

What if a bug is discovered in this program? The engineer can 
start the program debugger on the Model 370 HP SoftBench 
server This can be accomplished using the Actions:Debug menu 
pick of the development manager or the Tooi:Stari... menu pick 
of the tool manager, or by starting the HP SoftBench program 
debugger manually. The debugger again uses the distributed 
executiqn feature of the SPC to start an xdb process on the Series 
800 machine, debugging the object files created by the build 
tool. Finally, the engineer can start the static analyzer to browse 
through the static analysis information generated by the build 
tool. The static analyzer is running on the Model 370 HP 
SoftBench server and accessing data on the Series 800 data 
server 



software engineering environment. Like a communications 
satellite, the BMS receives messages from tools in the en- 
vironment and rebroadcasts these messages to all tools that 
have expressed an interest in each type of signal. 

When an HP SoftBench tool or a tool integrated using 
the HP Encapsulator starts up, it establishes a connection 
to the BMS and announces its command class (that is, the 
tool protocol it supports) and the operations it will service 
(its message-based API). It also tells the BMS what events 
it would like to be notified about if and when they happen 
elsewhere in the environment (that is. the messages for 
which it wants to define event triggers). See "Broadcast 
Message Server Message Structure," page 39. 

There are two types of messages in the HP SoftBench 
environment: notifications and requests. A notification is 
an announcement of an action, and a request is a tool asking 
the environment to perform an action. 




► X Display Connection 
— — m Data Connection 

• • . . p» SPC (Subprocess Control) Connection 



Fig. 1. An example of an HP SoftBench distributed develop- 
ment environment, 

Gerald P. Duggan 
Software Development Engineer 
Software Engineering Systems Division 



When a notification message is received by the BMS, it 
forwards the message to the tools that have informed the 
BMS that they would like to receive those messages. For 
example, in Fig. 2, the program builder tool has sent a 
notification that a DIRECTOR Y_BUILD was successfully com- 
pleted. The BMS forwards the message to tools that have 
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Fig. 2. HP SoltBench tools communicate through the broad- 
cast message server. Tools receive only messages they want 
to receive. 
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Schemes: Interface Consistency 



In the HP SoftBench environment, we wanted to distinguish 
regions according to the following functions 

■ Unchanging system information e.g.. prompt sthngs 

■ Changing system information e g . the function being exe- 
cuted m the debugger 

■ User area anywhere the user can enter text 

■ Readonly user area: a view of a read-only file 

■ Selectable regions buttons. 

The X11 window toolkit allows a choice of fonts, colors, and 
shadows for each region of an application mam window With 
the OSF/Motif appearance, regions can also be distinguished 
by 3D appearance Areas can appear to be raised, lowered, or 
flat on the window panel These collections of visual attributes 
organized by function are called schemes 

Information presented by the system, such as the current line 
number in the HP SoftBench program debugger, appears flat in 
the window The label for system information uses a bolder font 
than the value. In the main window for a tool, there is a single 
background color for all system areas 

Areas where the user can enter information appear recessed 
in the window and have a different background color from system 
areas Sometimes the user is prevented from entering information 
in a user area — for example, when a file being viewed has read- 
only protection. In these read-only user areas the background 
color is the same as the system areas. 

Regions where the user can select using the mouse (buttons, 
for instance) use a large bold font and appear raised. 

Windows that pop up (both menus and dialog boxes) use 
colors that associate them with the pull-down menu bars. 

Much of the human interface is implemented in HP SoftBench 
library routines shared by all applications. These high-level calls 
create widgets of known names. As a result, human interlace 
consistency is ensured and the number of resources needed to 
specify a scheme is minimized. Widget classes are used where 



possible to distinguish scheme components, but wnere a single 
widget class is used for more than one purpose, widget names 
or widget class hierarchies must be used 

Choosing a Scheme 

Schemes for monochrome and color are providea in three 
different font sizes. If the user does not specify a particular 
scheme by setting the Scheme resource, a scheme will be chosen 
based on screen resolution, visual class, and screen depth Font 
size is chosen based on the screen resolution. A color scheme 
will be used only if the screen has at least four color planes and 
the desired colors are available. 

implementation 

Scheme files are ordinary X1 1 resource files X1 1 resources 
are used to configure tools Each application constructs a re- 
source data base for itself. Some resources apply to all instanti- 
ations of a tool — for example, the arrangement of windows in an 
application. Others, the scheme resources, may depend on the 
particular display being used, Users can override resource val- 
ues. 

HP SoftBench tools have resource files not used by other X1 1 
applications. This was done to permit the sharing of resources 
between applications. Resources for code implemented in 
shared libraries are stored in the UbXe resource file. Scheme 
resources are placed in their own file. This approach allows easy 
configuration with all font and color specifications isolated and 
shared. 

John R. Diamant 
Colin Gerety 
Software Development Engineers 
Software Engineering Systems Division 



expressed an interest in this event. In this case, the develop- 
ment manager will use the message to trigger a directory 
update and the static analyzer will use it to trigger a 
reanalysis of its program data base. 

Often, no tools have expressed interest in a given mes- 
sage. When this is the case, the message is discarded. Tools 
get only messages they have requested. This serves to 
simplify a tool's message processing and substantially re- 
duce the message traffic on the network.* 

Tool Execution 

When a request message is received by the BMS, the HP 
SoftBench environment first checks to determine whether 
an already running tool has indicated through its API that 
it wUl service this type of request. If there is such a tool 
running, the HP SoftBench environment forwards the re- 
quest message to that tool.** If there is no such tool run- 
ning, the HP SoftBench environment checks a user-cus- 

' Slrictly speaking, "broadcast" message server is somewhat ot a misnomer, since only 
tools thai have explicitly requested certain messages are forwarded those messages The 
term "multicast would t>e mote accurate. 

"This explanation has been somewhat simplified An important factor in message dispatch- 
ing is the confexl at the message All messages contain a triple thai indicates the location 
ot the data the message is relemng to The HP SottBench environment uses this to dis- 
tinguish between multiple instances ot tools 



tomizable data base that contains the name of the appro- 
priate tool to start and instructions for starting it. The HP 
SoftBench environment then starts the tool and waits for 
confirmation from the tool thai it will indeed handle the 
request. Once this confirmation is received, the HP 
SoftBench environment forwards the queued request mes- 
sage to the tool just started. The HP SoftBench module that 
monitors the tools that are currently executing and invokes 
tools when necessary is referred to as the execution man- 
ager. 

In the HP SoftBench environment, as in the HP NewWave 
environment, but unlike the UNIX operating system, users 
do not have to start tools explicitly. They request actions 
on objects, and if a tool needs to be started, the execution 
manager starts it for them correctly and automatically. 

Distributed Support 

It is a fundamental goal of Ihe HP SoftBench environment 
to support development in a distributed computing envi- 
ronment. This is defined to include configurations of sev- 
eral hundred computers, composed of arbitrary combina- 
tions of X terminals, workstations, servers, and larger com- 
puters. The goal of HP SoftBench distributed computing 
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Pervasive Editing in the HP SoftBench Environment 



All HP SoftBench tools have common editing needs All must 
prompt the user lor input, and many provide views into source 
files. For consistency of the human interface, it is an HP SoftBench 
requirement that a common set of editing commands be used 
in all editable areas. The editing functionality exists in the HP 
SoftBench library and is shared by all the tools. Because the 
code is shared by all applications, consistency of appearance 
and behavior is ensured. 

The Edit Widget 

All of the underlying functionality needed by the editor was 
put into the edit widget. This includes insertion and deletion of 
text, cut, copy and paste, language dependent selection such 
as tokens or statements, and undo history. The edit widget sup- 
ports 16-bit characters and has language-sensitive editing capa- 
bilities. The availability of the widget makes it inexpensive to 
have this exact functionality in numerous places throughout an 
application. In fact, this single copy ot code is shared among all 
the HP SoftBench applications. An edit widget is used in all areas 
where a user can type information. 

A variant of the edit widget is used to provide selection from 
a lisl of alternatives, such as a list of filenames in the development 
manager directory list, function names resulting from a query in 
the static analyzer, or a list of mail messages in the HP SoftBench 
mail subsystem. 

One-Line Editables 

The human interface needed to include many areas for display- 
ing small user input windows that could be labeled with concise 
prompts, such as for a filename, an execution hostname, or a 
search string. These are implemented with a packaged combina- 
tion of a static text widget for the prompt and an edit widget for 
the user data. Called a one-line editable, this type of entity pro- 
vides the application writer with a single widgei to specify 
geometry placement. The individual constituent widgets allow 
specification of different fonts and background colors to inform 
the user which areas are constant and which are modifiable. 
Using such an editable gives the application all the power pro- 
vided by the editor in each input field, with no additional code. 
One-line editables are used in dialog boxes as well as in the 
application's main window 

View Space 

Applications often need one or more windows to display a 
view into a possibly large piece of text, such as the contents of 



support is to facilitate the use of the network and to hide 
from the user any complexities the network introduces. 

Remote Execution 

In the HP SoftBench environment, any tool can execute 
on any host in the network,* To support this remote execu- 
tion, HP SoftBench includes a distributed execution mech- 
anism designed to make the remote execution transparent 
to the HP SoftBench tools. 

To communicate with processes running on a local or 
remote computer, a high-level protocol is used. When com- 
municating with a remote computer, a small daemon pro- 
gram known as the HP SoftBench subprocess control (SPC) 

" On each computer where any HP SoftBench Toot or encapsulated tool will execute, the 
HP SoftBench product must be installed 



42 HEWLETT-PACKARD JOURNAL JUNE 1990 



a file or a set of debugger output messages Each such screen 
area is associated with a view space A view space provides a 
scrollable area for an edit widget, a place for a title, a filename, 
and a collection of indicators or buttons. 

The size of the view space is driven by the size of the edit 
widget, which can be specified in character rows and columns 
instead of pixels. The modifiability of the region is indicated by 
the background color The application can choose to hide the 
indicators selectively. Buttons not prohibited by the application 
automatically appear as needed. 

If several files or buffers share the same view space, an index 
button appears. This allows the user to select from a list which 
of the views in that space should be displayed. 

Viewing Files 

To insert a file into a view space, the application makes a call 
such as: 

DisplayFile(ViewSpace. DataHost, DataDirectory, DataFile, LineNumber); 

Access to a host other than the execution host is provided 
transparently to the application 

A similar interface allows the application writer to add annota- 
tions to a given line of a file. These annotations are displayed 
as small pictures in a window adjacent to the edit widget. These 
pictures ride with their associated line as the file is edited or 
scrolled. Annotations are used, for example, to denote debugger 
breakpoints or the program counter position. 

File Synchronization 

Since several applicalions may be viewing the same file, the 
file-viewing library routines provide for keeping these views syn- 
chronized with the tile syslem, using the broadcast message 
server (BMS). When the edit widget successfully saves a file, a 
file-modified message is sent, alerting other applications in- 
terested in the file. By default, the other applications automatically 
load the new file from disk. If there is risk of destroying a user's 
modifications, or if the user has so requested, a prompt box 
appears asking whether or not to reload the file. 

William A. Kwinn 
Software Development Engineer 
Software Engineering Systems Division 



daemon is used. This remote daemon is automatically in- 
voked through the HP-UX inetd facility. Process control be- 
tween the initiating tool and the remote process is then 
conducted through the SPC daemon. 

HP SoftBench tools communicate in a distributed envi- 
ronment via the BMS, as described earlier. This communi- 
cation mechanism is network-based so that tool communi- 
cation works identically whether all tools are local or each 
is on a different computer in the network. 

One of the most powerful applications of distributed 
execution is for special-purpose execution servers. For 
example, a project of ten software developers might wish 
to designate a dedicated (or otherwise lightly loaded) com- 
puter on the network to be used for all program builds 
(compiling and linking). With the HP SoftBench distributed 

(continued on page 44) 
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Native Language Support 



Localizabtlity has been one ol me goals lor the HP SoftBench 
product from the Beginning To this end. all of the code has been 
written to handle both 8-bit and 1 6-bit data (see Fig 1 ) The only 
limitations are imposed by some of the underlying HP-UX tools, 
such as res ana mkmf The HP SoftBench edit widget can receive 
16-bit input from the native language I/O facilities (see below). 
The fonts designed for the HP SoftBench environment include 
all of the HP Romans characters. 

The HP SoftBench environment uses the configurability of X1 1 
applications to full advantage Instead of putting localizable 
strings in message catalogs, we have opted to put them in X1 1 
resources. Localizers can redefine the values of X1 1 resources 
to translate HP SoftBench pull-down menus, button labels, 
prompts, and error messages. Because we have made maximal 
use of widgets that autoscale in size, there should be few places 
where localizers need to adjust screen layout parameters. By 
setting a single resource value, localizers can change editing 
commands from chorded combinations with the Extend char key 
to sequence combinations with the ESC key They can also use 
X11 resources to specify appropriate font schemes, and even 
lo refer to alternate Icon bit maps. 

In response to a request from the HP SoftBench developers, 
the X11 team added support for an environment variable that 
causes the system to search for application defaults in a specified 
directory, rather than in 'usr/iib/xn/app-detauits This allows the un- 
realized version and one or more localized versions of the HP 
SoftBench environment to reside on the same system. 

By setting a few environment variables and adding at most 
several lines lo Xdefauits, the user can use a localized HP 
SoftBench environment with virtually no speed penalty. 



Edit Widget 

The HP SoftBench edit widget is the core of all 8-bit and 16-bit 
data handling in HP SoftBench applications The user's textual 
data, either in the form of files loaded from the file system or text 
entered into editable fields, is stored and presented to the user 
through the edit widget This use of the edit widget makes it 
much easier for each tool to provide data integrity. 

Native language I'O support is part of the consistent editing 
facilities described in "Pervasive Editing in the HP SoftBench 
Environment" on page 42 Wherever the user can enter text within 
HP SoftBench tools, native language I/O is available. Because 
it is provided by the edit widget, it is transparent to individual 
tool implementors 

The edit widget is built on the P.2 version of the Xtlntrinsics 
At application start-up. it determines from the HP-UX environment 
variable, LANG, whether it needs to handle 8-bit or 16-bit data 
and makes appropriately configured buffer structures It also 
checks whether an Asian language keyboard is attached to the 
X server If the keyboard is Asian or if an environment variable, 
KBDJ.ANG, is set to an Asian language, the widget will activate 
a native language I/O server process. In the final product version 
built on the HP-UX 7,0 release, the HP X extension library provides 
much of the support necessary to handle all of HP's supported 
keyboards correctly. 

The design of the edit widget is based on object-oriented 
principles. Since a supported object-oriented language was not 
available on the HP-UX operating system at the start of develop- 
ment, we used a set of C macros to code in a simple but effective 
object-oriented style. The 8-bit and 1 6-bit capabilities are pro- 
vided by specialized subclasses of base objects, which provide 
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Fig. 1. The HP SoltBench envi- 
ronment with Japanese localiza- 
tions 
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mosl of the drawing and data storage functionality. At creation 
time the edit widget decides whether to create 8-bit or 16-bit 
pseudo-objects This allowed significant code sharing The lan- 
guage-sensitive actions of the HP SoftBench environment were 
added in a similar manner In this case one of the primary benefits 
was to allow two different engineers to work on tightly coupled 
code with minimal interference. 

Warren J. Graving 
Kathryn Y. Kwinn 
Software Development Engineers 
Software Engineering Systems Division 



(continued Horn page 42) 

execution capability, the team's environment can be cus- 
tomized to execute every user's builds on the dedicated 
compile server. This allows the team members to maintain 
full performance on their personal workstations while their 
compiles are performed on the server, which is not bur- 
dened with other tasks that might slow down the compila- 
tions. The same notion can be applied to any of the tools. 

Remote Data 

In the HP SoftBench environment, data can reside on 
any host in the network. Regardless of where a tool is 
running, it can access the data. The user provides an HP 
SoftBench file specification, which may contain an op- 
tional host field (e.g., machinel:/usr/src/project1/file1.c). If a re- 
mote host is specified, the distributed data facilities are 
automatically employed to establish the path to the remote 
file. 

With large teams, it is often easier to manage and ad- 
minister data centrally than to have the data duplicated on 
each workstation in the network. For example, configura- 
tion management, tape backup and archiving, and project 
management are typically easier when the project files are 
centralized. This was and remains one of the benefits of 
timesharing systems. 

The most common application of the remote data feature 
is the use of a data server. For projects that prefer or require 
dedicated computing power for each engineer, yet wish to 
have a common location for project data, the HP SoftBench 
distributed data capability facilitates this. Project members 
can run their tools locally but designate and use a common 
computer and file system location for project files (e.g.. 
fileserver: usr.'src/projectl ) . 

Remote Display 

HP SoftBench tools are built on the X Window System 
Version 11, which is a network-transparent window sys- 
tem. One of the benefits of the X Window System is that 
X programs can run on one system and display visually 
on another. In fact, to run the HP SoftBench environment, 
the only process that must actually be observable to the 
user is the X display server, which requires a bit-mapped 
display and adequate RAM. 

The extreme example of this is the X terminal products 
that are now appearing. These act as smart terminals that 
run the X display server and connect to the network. The 
HP SoftBench tools the user runs actually execute on other 
computers in the network. Moreover, the computers that 



actually run the HP SoftBench tools do not need to he 
running XI 1. They must simply support the Xll client 
library interface and be connected to the network. 

The HP SoftBench remote execution, data, and display 
capabilities described above enable diverse configurations 
of worksfations, servers, and larger computers to be em- 
ployed, based on the needs of the user's team, to increase 
software development throughput and decrease per-seat 
cost (see "Distributed Data, Execution, and Display," page 
40). 

User Interface Management 

To provide a consistent appearance and behavior among 
the many HP SoftBench tools, and to facilitate the use of 
the OSF/Motif user interface style, the HP SoftBench inte- 
gration services contain user interface management soft- 
ware. This software provides support for schemes (see 
"Schemes: Interface Consistency." page 41), pervasive code 
editing and viewing (see "Pervasive Editing in the HP 
SoftBench Environment," page 42), native languages (see 
"Native Language Support." page 43). and interactive help 
(see "Integrated Help," page 57). 

User Model 

The HP SoftBench tools have been designed so that they 
can support many different styles of work. A programmer 
doing rapid prototyping may use the same set of HP 
SoftBench tools as one doing maintenance, but they may 
be used quite differently, since the task is different. 

The programmer doing rapid prototyping may keep a 
"home base" in the program editor, while one doing 
maintenance may have a home base in the static analyzer. 
However, both have easy, integrated access to the other HP 
SoftBench functions such as file version management and 
program builds. 

In the HP SoftBench system model, each tool provides 
the actions that are appropriate based on the type of data 
managed by the tool. For example, in the program editor, 
source files are viewed and manipulated. However, the 
programmer can also check in and out the currently edited 
file, cause the file to be compiled, and ask static analysis 
queries, such as where a given function is defined. The 
static analyzer provides cross-reference and code browsing 
information, yet the programmer can edit the files being 
viewed, check them in and out of version control, and 
cause the files to be rebuilt. This remote access to other 
tools' functionality is provided by the HP SoftBench tool 
communication architecture. It lets the programmer con- 
centrate on the task at hand, while the tools cooperate 
among themselves to perform requested operations. 

Human Interface 

The HP SoftBench environment provides an object-ac- 
tion user interface model. The user first selects the object 
that will be operated on. and then selects one or more 
actions to be performed on that object. The environment 
works to provide a task-oriented, rather than a tool-oriented 
view of the environment to the user. The HP SoftBench 
user interface style was significantly influenced by the HP 
NewWave user interface work. 9 
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Mechanisms for Efficient Delivery 



The HP SoftBench environment cs composed o! several com- 
municating processes, all running under the HP-UX operating 
system and the X Window System Version 1 1 Each HP SoftBench 
tool is built on the X Version 1 1 C library interlace, the X toolkit 
the HP widgets, and the HP SoftBench common code library 
Most X toolkit applications are very large because of the sizes 
of the required libraries. Each of the dozen HP SoftBench pro- 
cesses would be well over a megabyte in size if it were linked 
m the standard fashion, having its own private copy of all the 
library code. 

To deliver the HP SoftBench environment effectively, we de- 
veloped a delivery technology that significantly reduces the size 
of the tools and improves the performance To the user, these 
facilities are completely transparent. The user runs HP SoftBench 
tools just like any HP-UX program or shell script. These facilities 
are not available to the end user They are used only to ensure 
effective delivery of the HP SoftBench tools 

The large executable size is a problem, but not only because 
of the disk storage space required. With several of these pro- 
grams all running at once (as they typically are in the HP 
SoftBench environment), the physical RAM in the computer can 
be exceeded by a large factor The virtual memory system allows 
the system to continue to run, but performance degrades as 
more pages of memory are moved to the swap device. 

The solution was to have just one copy of the library code, 
rather than many. The common library for all the HP SoftBench 
applications is about one megabyte in size. All of the SoftBench 
tools (except the HP Encapsulator) are less than 200K bytes in 
size when stripped of their private copies of the library. 

Implementation 

The idea of shared libraries is not new Many UNIX implemen- 
tations support [hem. However, no shared library facility existed 
on the HP-UX operating system at the time we needed it for our 
product, so we implemented our own There were some technical 
choices to be made: 

■ Where should the shared code physically reside so that it can 
be accessed simultaneously by all of the tool processes? 

■ How can the individual tools be linked to Ihe shared code so 
that the addresses of entry points and globals are properly 
resolved? 

■ How can the various tools be invoked such that the attachment 
to the shared library is transparent to the user? 

Storing the Code 

Our first approach was to use shared memory segments. These 
are regions of memory that can be created by one process and 
then accessed by many others. We loaded Ihe library code into 
one or more of these segments. Any tool could then attach to 
these segments and execute code directly out of them This was 



The HP SoftBench environment follows the OSF/Motif 
appearance and behavior. This interface technology is 
largely mouse- and menu-driven, with human-computer 
interaction occurring primarily through dialog boxes (see 
Fig. 3). 

Several benefits are provided by the OSF/Motif technol- 
ogy: 

A rich set of primitives on which to build sophisticated 
user interfaces. 



conceptually very simple We could put each separate library 
(iibca nbxii.a. loxta, etc ) into its own segment, and each appli- 
cation only had to attach to as many segments as it needed 
However there were problems with this approach First of all, it 
required an explicit step m the initialization of the environment 
to create these segments and load them It also required some 
user action to deallocate them when taking down the environ- 
ment Also, on HP PA-RISC computers, there was a performance 
degradation if an application needed more than two of these 
segments 

The solution was to put all the library code into a demand-load- 
able executable program The HP-UX system automatically 
shares the code of such an executable if it is being executed 
simultaneously by multiple processes. 

Linking the Code 

At first we tried to link each of the tools statically to the library 
code The HP-UX linker id has a special option to do this. This 
approach would have been the most straightforward way of de- 
livering the product to users, but we found that it was too inflexible 
Once the tools had been statically linked to a particular library, 
any changes to the library required relinking all the tools We 
needed rapid prototyping: as we changed or added features to 
the library, we wanted to test the changes quickly without having 
to rebuild everything. 

The solution was to delay linking the tools until run time A 
dynamic loader resolves external symbols and relocates the code 
when the application is loaded This link step is very fast (1 to 2 
seconds) because it all happens in memory The tools themselves 
reside on disk as standard unlinked ,o files. 

Invoking the Tools 

As a result of the decisions |ust described, all HP SoftBench 
tools are invoked by running a single, large, demand-loadable 
program that contains a dynamic loader and all of the common 
library code for the product This program is called runprog until 
it becomes part of the HP SoftBench product. It is possible to 
run any of the HP SoftBench tools by executing runprog explicitly, 
but there is a quick trick that hides what's gomg on. We use the 
HP-UX in command to give runprog several aliases There is still 
only one runprog, but each of Ihe HP SoftBench tools is actually 
lust another name for it Runprog figures oul which tool to run by 
looking at its own invocation name. argv|0), then appends o to 
that name and invokes the dynamic linker Now HP SoftBench 
tools can be executed transparently as in any other HP-UX pro- 
gram or shell script. 

Sam Sands 
Software Development Engineer 
Software Engineering Systems Division 



■ Keyboard traversal for users who prefer to perform some 
or all operations from the keyboard rather than with a 
pointing device. 

■ Native-language input and output for accepting and dis- 
playing languages requiring 8-bit and 16-bit character 
sets. 

■ User-definable keyboard accelerators for common menu 
actions. 

■ Consistency with PC-based applications to facilitate in- 
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Application of a Reliability Model to the HP SoftBench Environment 



The HP SoftBench team decided to incorporate a statistical 
reliability model into the data gathering process during the sys- 
tem test phase to help us better understand the current quality 
level of the code and predict how long it might take to attain a 
given quality level The model is based on the work of Kohoutek, ' 
with additional results from Musa. Okumoto. and Goel 2 3 Similar 
models have been used in other HP Divisions ' 1 5,6 We learned 
of it from Doug Howell. 7 

The basic idea is to fit a logarithmic Poisson execution time 
model to the plot of defects found versus time At time t (in hours), 
the number of defects found, u(t), is given by 

u(t) = 9(1 -e - "") 



where 0 is a scale parameter and K is the defect finding rate. 

Each week, when we had a new data poml on Ihe graph of 
detects found versus test hours, we used nonlinear least squares 
iteration to find the 8 and K lhat produced a best tit of the u(t) 
curve to our data From the very beginning, the fit of the curve 
to our data points was remarkable. 

The scale parameter f> is the limit of the function u(l) as t 
approaches infinity— that is, il is the number of defects the model 
predicts are in the product. We found the stability of flover time 
to be an interesting subiect; we will say more about this below. 

The first derivative of u(t) is the rate at which defects are being 
found. The reciprocal of the finding rate is the instantaneous 
mean time between defects (MTBD) at time t: 

MTBD = 1/u'(t) = (1/\)e x " s 

This equation was extremely useful, since it allowed us each 
week to predict when a given MTBD would be achieved. We 
solved this equation for t for various values ol MTBD, given the 
current values of 0 and X. We then converted t from hours into 
calendar time by dividing by the average number of test hours 
we were logging per week 

This gave us a weekly prediction of the calendar date when 
we would achieve an instantaneous MTBD equal to our goal. We 
noticed that » (hence the prediction) was fairly unstable at first. 
Then we fitted u(t) to different data. Instead of computing 0 based 



on the plot of raw unweighted defects versus test hours, we used 
what we call filtered weighted defects Duplicate reports and 
enhancement requests were removed from the count, and de- 
fects were weighted according to the severity assigned to them 
by the project team (on a scale from 0 to 1 ) 

This of course gave us an MTBD that meant something different 
than before 11 was now the instantaneous mean time between 
virtual defects of weight 1 instead of the time between any defects 
found, regardless of seventy We decided that this new MTBD 
number actually meant more, given that the SoftBench product 
is user-interface-inlensive and many people were submitting low- 
weight defects that were stylistic, personal preference issues 

When we switched to computing fl based on the filtered weight- 
ed defect plot, it became quite stable Several months ahead, 
we predicted that we would reach our MTBD goal on a particular 
date The actual MTBD on that date was 95 7% of the goal, and 
we reached the goal and did our final build five days later 

We feel that the use of this simple model was very successful 
m achieving the objectives of understanding where we were and 
providing a rational (as opposed to emotional or schedule im- 
posed) prediction ot when we would be finished 
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teroperability across computing platforms. 
Conclusion 

We have described the various mechanisms provided by 
the HP SoftBench tool integration architecture for tool com- 
munication, distributed data, execution, and display, and 
user interface management, The communication facilities 
are exploited by the HP SoftBench software development 
tools to collaborate in presenting a task-oriented environ- 
ment to the programmer. The distributed execution, data 
and display services are used by the tools to allow the user 
to make effective use of the computational, file storage, 
and presentation capabilities available on the network. 
This can improve performance, reduce per-seat worksta- 
tion cost, and facilitate development for large software 
teams in a distributed environment. The user interface 
management facilities allow the tools to present a consis- 



tent, localizable, customizable environment that is easy to 
learn and use. 

The HP Encapsulator provides these integration services 
to existing nonSoftBench tools, without requiring access 
to the tools" source code. 
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A New Generation of Software 
Development Tools 

The HP SoftBench environment's development manager, 
program editor, program builder, static analyzer, program 
debugger, and mail collaborate to support task-oriented 
program construction, test, and maintenance. 



by Colin Gerety 

HE HP SOFTBENCH PRODUCT, as explained in the 
article on page 36, provides an integrated software 
development environment designed to facilitate 
rapid interactive program construction, test, and mainte- 
nance in a distributed computing environment. This article 
presents examples of computer-aided software engineering 
(CASE) tools that use the services of the HP SoftBench tool 
integration architecture. 

The HP SoftBench environment is designed for software 
development teams that have the following characteristics: 
They need strong program construction, test, and mainte- 
nance support. 

They want to automate tasks in their development pro- 
cess. 

They want a task-oriented system that is easy to learn 
and use. 

They want lo integrate their existing tools into their de- 
velopment environment and processes. 
The HP SoftBench environment is designed so that users 
can focus on software development tasks rather than on 
the specific tools needed to accomplish the tasks. Instead 
of having to specify tools, arguments, and data for each 
step required to perform a task. HP SoftBench users select 
an object to operate on (for example, an executable file) 
and then specify what they want to do (for example, debug). 
The environment determines what tools to run. what 
machine to run them on, how to start them, what arguments 
are required, and where the data resides that they will 
operate on. On the other hand, HP SoftBench users who 
prefer the conventional tool-oriented mode of operation 
can work in that mode at their option. 

The HP SoftBench tools collaborate to support five 
targeted software development tasks. Two of these — team 
file management and team communication — are pervasive. 
The other three — program construction, program testing, 
and program maintenance — support specific software life 
cycle phases. A set of HP SoftBench tools assists the user 
with each of these five tasks. The current HP SoftBench 
release supports software development in C, Fortran, and 
Pascal. 

Team File Management 

Teams of software developers working together need 
ways to manage access to and revisions of the files that 
compose the software project. Team members need a stable 



and controlled area to develop and test the project software. 
They also need an easy way to retrieve changes and addi- 
tions to the project files made by other team members, so 
that they can test their own changes with the latest version. 
Once they are satisfied that their modifications work with 
the latest version, they need to submit or promote Iheir 
modifications or additions into the master set of project 
files. The HP SoftBench development manager provides 
these services (see box, page 49). 

The notions of reserving, locking, or checking out a file 
and then replacing or checking in the modified file are 
central to all development, test, and maintenance activities. 
Therefore, all HP SoftBench tools that allow modification 
of project source files communicate directly with the de- 
velopment manager to retrieve the current file from the 
version management system or to return it. 

For example, if you are a developer who wants to modify 
a file, you request access to the file through the develop- 
ment manager. If another developer is already in the pro- 
cess of modifying that file, the development manager de- 
nies the request and tells you which team member is al- 
ready working on the file. In this case, you can either ask 
the development manager to create a branch, which will 
need to be merged with other changes later, or you can 
contact the named team member, either directly or through 
HP SoftBench mail, to negotiate access to the file. 

In addition to this team support, standard versioning 
operations are provided, such as storing change informa- 
tion for files so that previous revisions can be retrieved. 
Also included is the ability to tag specific file versions 
with symbolic names, such as Release 1.0. or with specific 
states, such as Experimental. Sets of files that make up particu- 
lar configurations of the project can be stored and retrieved 
on demand. You may want to retrieve, for example, all the 
files that make up Release 2.0 or all the files for a certain 
HP-UX version that have been tested. You might also ask 
to retrieve the project files as they were on January 9. 

Team Communication 

HP SoftBench team communication support is designed 
to facilitate communication among members of the project 
team so that shared resources are efficiently used, develop- 
ers are notified of key system events, and work and meet- 
ings can be arranged and coordinated. Like team file man- 
agement, team communication is a pervasive task, neces- 
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Development Manager 



The HP SoftBench development manager manages the ver- 
sions of Tiles on which the other tools operate Fig 1 shows the 
development manager user interlace. The user can check files 
m and out, examine change histories, and compare revisions 

In the development model supported by the development man- 
ager, each person has a private, local work area, which is as- 
sociated with a learn or master work area. The development 
manager presents a view of the files m the user's work area 
along with the state of each file (file type, whether il is under 
version control, whether il is locked or writable) 
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Fig. 1. Development manager user interlace 

The version management functions provided by the develop- 
ment manager can be accessed directly through the develop- 
ment manager user interface or Indirectly from Ihe other tools 
via the development manager's message interface For example, 
all HP SoftBench tools that provide the ability to edit source files 
(e.g.. static analyzer, program builder, program editor) allow the 
user [o check files in or out from version control. The tools do 
this by communicating with the development manager to perform 
the requested services. Thus the development manager's version 
conlrol is pervasive throughout the environment. 

The development manager also serves as an application 
launcher. Actions are presented based on the file type For exam- 
ple, Ihe user can run, rebuild, or debug an executable file and 
edit, compile, and show functions of a C source file. Some actions 
are serviced directly by Ihe development manager, while others 
are forwarded via Ihe broadcasl message server lo other HP 
SoftBench tools or user encapsulations. 

Anthony P. Walker 
Software Development Engineer 
Software Engineering Systems Division 



sary in all phases of software development. 

The HP SoftBench product includes an electronic mail 
facility, HP SoftBench mail (see Fig. 1). Besides the stan- 
dard electronic mail capabilities of viewing, replying to. 
and filing messages from others and composing and for- 
warding messages to others. HP SoftBench mail is designed 
to link into the rest of the software development environ- 
ment As an example of such a link. HP SoftBench mail 
can be instructed to watch for the completion of a system 
build and send out an announcement to members of the 
team if the build fails. If the build is successful. HP 
SoftBench mail can announce the success, letting the team 
know that a new release of the software is available (see 
Fig. 2). 

More information on the HP SoftBench mail tool can be 
found in the article on page 59. 

Program Construction 

Program construction is the transformation of a design 
into an executable program. The HP SoftBench environ- 
ment supports either writing new source code or assem- 
bling software from existing components, or a combination 
of the two. 

Large projects often contain one or more common code 
libraries, designed to be reused throughout the application. 
Software reuse of this sort has been shown to be a major 
factor in improving both software quality and productivity. 
The HP SoftBench environment facilitates software reuse 
by addressing one of the common obstacles to reuse: locat- 
ing appropriate functions and procedures. The HP 
SoftBench static analyzer (see box. page 54) assists in this 
task by making it easy to search the project libraries, looking 
at parameters, return values, and function definitions. 

Programs are created, modified, or synthesized from 
existing pieces in a program editor. The HP SoftBench pro- 
gram editor (see box, page 51) assists with this task, and 
provides quick access to the other program construction 
tools. For example, the user can select a function name in 
a program and ask the HP SoftBench environment to show 
the definition of the function or other references to the 
function within the application. The user can also check 
the syntax of the program file under construction. The pro- 
gram editor is targeted at programmers who are new to the 
HP-UX operating system or who have worked in PC envi- 
ronments and want a mouse- and menu-based editor. II the 
user already has a favorite UNIX program editor, such as 
emacs or vi, the HP SoftBench environment allows the use 
of that editor instead. 

Once the program source files have been created, the HP 
SoftBench system analyzes module dependencies and con- 
structs a recipe, or makefile, for building executable pro- 
grams or libraries. The HP SoftBench system then builds 
the program, compiling and linking only modules that are 
out of date. If compile or link errors are encountered, the 
user can correct them interactively. The HP SoftBench pro- 
gram builder (see box, page 52) assists with this task. 

The result of the program editor, program builder, and 
static analyzer working together is a rapid edit-compile 
cycle allowing quick exploration of alternative implemen- 
tations or construction of new functionality. 

Ileit continued on oage 54| 
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SoftBench - Mail 



IDH 



Mail Folder Message Settings Help 



letters: 



1 steveGhpfoo.sde.hp.com Wed Nov 1 15:62 13/398 File callbacks. c 

2 james$hpgvd. sde.hp.com Wed Nov 1 15:62 13/398 Build Successful 

4 chris@hpcnw.sde.hp.com Wed Nov 1 15:82 15/414 Project Milestones 



am 

H 

a 



tMrtr. 




Reply to Authoi... 




Print 


Compose... 


Baflfe 




Reply to All... 




Forward... 


Ltsi Folders... 



Hessa ge-Id : <98B2 1 22285 . A»8«378f!hpba r . sde . hp. com) 
To: colin@hplsf.sde.hp.com 
Subject: Release Fart/ 
Status: RO 



There will be a party to celebrate the success of 
the Tower project on Jan 18, 1998. Hope 
you can all be there: 

Place: Cuisine Cuisine 

Time: 8:88pm 

Date: January 1B, 1998 

Attire: Black Tie 

RSVP Requested. 

Janet 



Fig. 1. HP SoftBench mail user 
interlace. 



SoltHench - Mall 



Mall Folder Mas 



System mailbox: 



1 claire_phi 

2 cagan@hpfc 

3 carol_slac 

J3ED 





3 


Delete 


Re'flc 





To: cagan@hpfcjr 
Subject: Re: Ano 

Hi Marty, 

Yes the other ma 
and gave the add 

Janet In 
INRIA - 
Route de 
86565 Va 
FRANCE 

thanks again. 

see you 
janet 



Triggers 



Release Announcement: 
Send to: T 



<> Active 



Annotations: 



Successful fluild Am 

Send to: ["^7 
Annotations: 



^ Active 



The tower project has just been successfully 
built. You can update from your Development 
Mana ger . 



Failed Build Announcement: 
Sendlo: [7711 



♦ Active 



Annotations: 



The tower project build has failed. The error 
log is attached. Please correct ASAP. 



Close 



Visit 
ntegr 



I 



Fig. 2. Setting up HP SoftBench 
mail triggers. 
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Program Editor 



Editors are controversial Despite considerable reluctance. 
Dased on our conviction that there are already too many editors 
for HP-UX programs, we found ourselves writing a new editor 
for the HP SoHBench environment Tne requirements that forced 
this decision were: 

■ Language sensitivity. The primary joD of the HP SottBench 
editor is program editing. To be effective, the editor should 
be language sensitive This ruled oul the TextEdit widget in the 
X toolkit 

■ Ease of learning and use. We wanted an easy-to-use mouse/ 
menu interface consistent with the other HP SottBench tools. 

■ Embedded edit capabilities. The HP SottBench tools must 
prompt the user for information These prompts may be em- 
bedded in the tool window. Without a difficult encapsulation, 
stand-alone editors like emacs or vt cannot be used in this way 

■ Consistent interface. It was an HP SottBench requirement lhat 
editing commands be consistent in all editable areas of all 
tools 

■ Broadcast message support To be a good citizen of the HP 
SoftBench environment, an editor should make its functionality 
available through messages and make other tools (e.g.. the 
HP SoftBench program debugger) available from the editor 
To satisfy these requirements, we created the edit widget (see 

page 42) Given the edit widget, the editor is |us! a sophisticated 
wrapper on the existing functionality 

A user can configure the system to have edit requests serviced 
by another editor but one or more of the goals of the system 
editor will be sacrificed If vi is chosen, consistency and broadcast 
message support are sacrificed. II emacs is chosen, the consistent 
mouse/menu human interface is sacrificed. 



In the HP SoftBench program editor, each file is given its own 
window ano menus are used to give easy access to the editing 
functionality (see Fig 1 ) Messages are used to communicate 
with the HP SoftBench program builder, static analyzer, and de- 
velopment manager tools 

The HP SoftBench editor is designee for editing programs, as 
opposed lo general prose It has knowledge of program struc- 
tures like procedures, blocks, and tokens and can use this infor- 
mation to control indentation and balance delimiters 

The easy-to-use menu/mouse interface is particularly effective 
for writing code In the HP SoftBench environment there are 
mouse functions for selecting tokens, blocks, and procedures 
and there are mouse functions for cut. copy, and paste opera- 
tions Because program code involves repeating similar struc- 
tures, code can be written very quickly in the program editor by 
copying a structure that is similar to the needed code and chang- 
ing it to the desired form 

For example, once code similar lo what is needed is pasted 
into place, a typical change is in the names of variables The 
edit widget replaces selected text with whatever is typed next. 
To make a change in the name of a variable that occurs several 
limes, the first instance of the old variable name is selected by 
double-clicking the left mouse button The new name is lyped, 
replacing the old name. The new name is then selected and 
copied into the paste buffer Additional instances are changed 
by selecting the old token and pasting the new loken in its place. 

Colin Gerety 
Software Development Engineer 
Software Engineering Systems Division 



SoftBench — Program Editor 



File Cdit Buffer Procedure Block Token Help 



file: hpf cure: /user s/cagan/Pro ject/T 



•>)) Show Definition 



■>)) Show References 



C 

N/A •')) Show Classification 

Experimental (Do Ot LUstriOUte J 



* Language: 

* Package: 

* Status: 
* 

* (c) Copyright 1989, Hewlett-Packard Company, all rights reserved. 
* 

* t , . . f W «o»Mt****lMc*«M»n«*»**i^^ 
»/ 



tinclude "touer.h" 
tinclude "audio. h" 

extern Widget ring_list[J; 

extern Display *di:play; 

extern PIN pin[]j 

extern Boolean audio_value; 

void W!HWW|y? (f rom. to, disk_number) 
int from, to, disk_number; 

( 

int new_x, new_y; 
Arg wargs[2]; 

/* adjust pin count */ 




Fig. f. Program editor user inter- 
lace. 
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Program Builder 



The HP SoflBench program builder is a tool thai simplifies the 
compile and link phases of the typical edit/compile/link/debug 
loop used during software development (see Fig. 1). It shortens 
this part of the cycle by compiling only the parts of a program 
that require recompilation because of direct or indirect changes 
In addition, the program builder provides an error browsing fea- 
ture that facilitates direct access to identified source code errors, 
thereby speeding up the edit phase of this cycle. 

In an effort to simplify further the task of building and maintain- 
ing a software project, the program builder provides facilities for 
creating and maintaining the dependency control files required 
for intelligent builds This frees the user from having to deal with 
the format and content of such files 

Rebuild Only What Is Necessary 

The program builder compiles only the parts of a program that 
have changed since the last build If an include file common to 
several source files has changed, the program builder is smart 
enough to compile all files that depend on (i.e.. include) that file 
This ensures that any change will be correctly propagated 
through the entire software project. 

In reality, it is not the program builder that performs these 
dependency control tasks. It is the build program invoked by 
the program builder that has these abilities The program builder 
provides a friendly and consistent user interface to this underlying 
program The UNIX automatic dependency control program make 
is the default program used to provide this functionality Make 
does its job by using time stamps maintained by the file system 
to determine if source files have changed since the last time they 
were compiled. If any files (or dependent files) have changed, 
make will invoke the appropriate compiler to recompile only those 



files and relink them. 

Although the default build program is make, almost any build 
program can be substituted. The program builder does not care 
what build program is run. This makes it very simple to adapt to 
new build technologies. The only thing that really needs to be 
known about the build program is how to pass compiler flag 
information through it to the compilers The program builder must 
be able to control certain compiler behavior, including the gen- 
eration of information required to debug a program, the genera- 
tion of information required for static analysis, and the optimiza- 
tion of code for speed. This is necessary because the program 
builder message interface allows specification of parameters that 
request these behaviors For example, the static analyzer tool 
will always request static information when it sends a build re- 
quest to the program builder 

By default, the program builder passes compiler flags through 
well-defined environment variables that all HP compilers know 
to look at, effectively bypassing the build program. Therefore, 
almost any build program and related makefile should be usable 
without any changes to the program builder configuration or 
makefile. 

For some build programs, such as the AT&T ToolChest pro- 
gram nmake, which keeps track of the compile options used to 
do a build, this scheme is not acceptable. Nmake will force all 
files to be recompiled if compile options change Therefore, the 
program builder can be configured to pass compile options 
through the build program on the command line using almost 
any syntax that is appropriate for the build program or makefile. 

Automatic Generation of Dependencies 

For make to do its |ob, there must be a makefile that contains 



SuflllLMlLh - PfUI|ldITI fllHl(|..M 



Fill! filit Bullet Makefile Actions Setting* Help 



Cotile»l: hpfcmrci/users/casjen/ProJect To' 
Option*: f[ 



latget: 



CCOPTS— | -y; FCOPTS— | -Jtj PCOPTS— | -y 



Step. 

Non-Zero lUtut from child process. 
BUILD-TARGET Felled 



Etiutv Fkit p.evlou* tie, t Lett 



hpf cmrc:/u9ers/cag»n/ProJect/Tower/logic. c 



nr-_» - pin[to]. location - ( (MHC_VIDTH_F ACTOR a di sk_nuir,ber ) 
ne-.y - PAHEL.BE IGHT.FACTOR - (pint to) , r mg_count • R1K5-REK 

Xt5etArg(wargst8], XndlK, tMU&\ 
XtSetArgtwargslW. Xm»r. ne»_jr>; 

»tSotVelues(rin(_llsttdisk_number-tl, »ar s s, 2); 

l( (ludio_»elur " True) 

beeplVOICE, FITCH • j-UIJtllU.Hf . VOLimE, DURAT: 

!leep(PAU5E_D0RATIO») l 



void shuffle (from, to, spare, number) 
int from, to, spare, number; 

< 

if (number •* t) 

»ovr.rlng(f rom, to, number); 



Fig. 1. Program builder user interface. 



So'THpnch — 1'roijr^ni llnililpr 



filit tfufter '■' ... File Actio 



Sellings Help 



OiJliix 



CCOPT 



firm*; 

hpf cmr 



I'roqi am Huiltlei 



-■'■it Prog? «ui. Mali- tile: 
PROCHAM. 



tWlAGS: 
DIRS: 



IBS: . .Aib/libutil... 



•/ 

/• 91$ 

* i f ndef _5Y5_EItE_I,VCLUPED /• allow* multiple Inclusion •/ 
•define _<YS_FILE_IHCLUDED 

•ifdef KERNEL 
•include ./h/typ*s.h" 
"•include "../h/fet.tl.h" 
•else 

•include <sys/typ*s.h> 
•include <fcntl.h> 
lendif 



■ Descriptor table entry. 

• One for each kernel object. 



Fig. 2. Creating a makefile in the program builder 
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a list of source files required to construct the program The 
makefile must also contain dependency information (what files 
depend on what other files) so that efficient builds can be per- 
formed For many UNIX users, for all Put the simples! set of 
source files, makefiles are quite magical and for the most part 
unintelligible Maintaining them is a nightmare, and creating them 
is very difficult. The program builder provides a user friendly 
interface for the creation and maintenance of these files It auto- 
mates these tasks oy using the HP-UX program mkrrri (make 
makefile) for both creation and maintenance 

To create a makefile, the Makefile Create Program menu selection 
is used. A simple fill-in-the-bianks form is then displayed m a 
window (see Fig. 2) All entries are optional, but the user typically 
will specify items such as an executable file and any extra libraries 
to be linked with the program. After the OK button is pressed 
the program builder causes mkmf to scan all of the files m the 
context directory and construct a makefile based on the depen- 
dency graph generated from its analysis of the source files. The 
program builder supports creation of makefiles for archive li- 
braries as well as for programs 

To update a makefile, the user simply selects the Makefile: Update 
menu selection. The program builder will then invoke mkmt to 
rescan all source files and update the dependency information 
in the existing makefile. 

Makefiles can contain numerous targets for performing a vari- 
ety of tasks other than building a program Specifying one of 
these targets in the TARGET window of the the program builder 
and starting a build (pressing the BUILD button) causes the action 
associated with that target. Some of Ihe targets provided in 
makefiles generated by the program builder include: 
« print Format all of the source files and output to the printer. 

■ lint Run lint over the source files to check lor syntax errors. 

■ clobber. Remove all reproducible files (.o files, program files, 
core files, etc) 

■ clean Remove all object (.0) files. 

■ touch Touch (update the time stamp of) all source files 

It is often desirable for more experienced users to customize 
the actions associated with these targets or to add new targets 
for additional functionality To this end, a menu selection (Makefile: 
Edit) is available so that the makefile can be edited in the edit 
area of the program builder or in a separate window, 

The program builder attempts to deal gracefully with build 
requests when no recognizable makefile is present It is often 
Ihe case that a single directory may contain numerous simple 
self-contained programs While it is currently not possible to in- 
struct the program builder to build all of the programs In the 
directory without a makefile, requests to build individual pro- 
grams are handled correclly. 

Error Browsing 

A useful feature of the program builder is the error browser 
The program builder presents compilation errors lo the user in 
a browsable list. It is a simple matter for a programmer to walk 
through the list of errors, fixing them one at a time. 

Error recognition is based on regular expressions and therefore 
is easily extensible The regular expressions are stored in a file 
and read into the program builder during initialization The file 
supplied with the program builder contains expressions for all 
of the languages supported by the HP SoftBench system (HP 
9000 Series 300 and Series 800 compiler errors are recognized) 
The user can supply a file to be used in place of the default file. 

To be recognized, all errors must contain a filename and a 
line number The error need not be specified on a single line, 
but may span several, as for the Series 800 Pascal compiler 
The file thai conlains the regular expressions supports syntax 



that allows the user to specify how many expressions must be 
matched to recognize a line or set of lines as an error. 

Each line received by the program builder from the build pro- 
cess is shown in the build output area and compared wrth the 
current list of known regular expressions If it matches one of 
the expressions (or matches the last line of a multiple-line expres- 
sion whose preceding lines have already been matched), the 
filename and line number are stored in the list of recognized 
error lines Selecting any of these lines will display the associated 
source code line Kl the file view area. Tne error buttons (FIRST 
next, etc ) are available to cycle through the errors in an orderly 
manner The program builder uses features supplied by the HP 
SoftBench edit widget (floating line marks) to ensure that error 
line references remain accurate as source code lines are inserted 
or deleted. 

This facility is not limited to compiler errors A useful example 
of its flexibility is a grep browser The program builder can be 
configured to act as one by changing the build program (either 
via the menu or by a resource specification) to grep, specifying 
- n m the program builder OPTIONS window to ensure that grep 
generates line numbers in its output, and specifying a pattern 
and a list of files to search in the OPTIONS window. The regular 
expression for recognizing grep output is already present in the 
default regular expression file supplied with the program builder. 
Now when a build is performed, all output from grep will be 
recognized as errors Thus, selecting any of the outpul lines or 
using the error buttons (FIRST. NEXT, etc ) will display the selected 
file at the indicated line number in the file view area of the program 
builder tool. This flexibility can be used to create a browser for 
many tools. 

Remote Builds 

The program builder supports a simple distributed or remote 
build facility in addition to the standard HP SoftBench remote 
execution and remote data facilities (see "Distributed Execution, 
Data, and Display," page 40). This allows users to specify any 
machine in the network (to which they have access) to be used 
as a compile server While this facility does not implement true 
distributed builds (builds where the various compiles and links 
needed to complete a build request are distributed across vari- 
ous computers on a network), il does allow the user lo assign 
Ihe compute and I/O intensive task of compiles and links to a 
machine that may be better able to handle these demands. Be- 
cause of its simplicity, the program builder does not preclude 
true distributed builds. Any build facility capable of such a task 
can be substituted for the UNIX make program. 

The HP SoftBench subprocess control (SPC) facility is used 
for automatic execution of the build process on the specified 
remote computer. Before the process Is started, the SPC daemon 
on the remote machine establishes a data connection to the 
machine and directory specified by the program builder's data 
context The current working directory for the build process is 
then changed to match that of the context host and directory, 
and ihe build is then performed as if it were run locally. 

James W. Wichelman 
Software Development Engineer 
Software Engineering Systems Division 
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Static Analyzer 



The HP SoftBench sialic analyzer aids the user in understand- 
ing source code. Fig. 1 shows its user interface. II supports 
language independent queries aboul code siructure and pro- 
vides cross-reference information thai can help in finding defects, 
planning code changes, or evaluating a piece of software for 
reuse Message communication wilh the developmenl manager, 
program editor, and program builder enhances its ability to pro- 
vide window-based, interactive analysis 

The static analyzer receives its information from the compiler, 
much the same as a debugger does This has the advantage 
that source code is parsed once and the results are shared 
between static analysis, debugging, and program execution. 

The compiler collects cross-reference information for the static 
analyzer on all identifiers within a program and categorizes each 
occurrence by how it is used An assignment statement is 
categorized as a modification to the identifier being assigned to, 
while a variable definition is categorized as a definition The static 
analyzer supports queries that return a single category or group 
of categories of references about an identifier Often a user only 
wants to see where the value of a variable has been changed 
or how a function has been defined or declared in different mod- 
ules. The static analyzer supports these queries directly, return- 
ing only the relevant information 

A program may have many identifiers that have the same name, 
but because they are different program elements or have different 
scopes, they refer to different objects. For instance, a structure 
field named slime may be defined within two different structures 
and therefore represent two distinct entities that should not be 
confused during analysis. When only the name slime is entered 
and its uses are requested, the static analyzer will return the 
uses of both fields because both are named slime and have uses. 
However, if the user identifies slime by selecting it within a source 
code view, then there is enough location information to indicate 
which field is wanted, and only the references to the selected 
slime will be returned. 

Coupling these capabilities with program structure queries pro- 
vides a tool streamlined for understanding and facilitating 
changes to software. By allowing the user to ask questions about 
a program, browse results to see program context, and use the 
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Fig. 1. Static analyzer user interlace 



built-in language-sensitive editing, the HP SoftBench environ- 
ment provides the user with a productive environment for software 
understanding and software change 

Gary L. Thunquest 
John P. Button 

Software Development Engineers 
Software Engineering Systems Division 
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Program Test 

The program construction task results in an executable 
program. However, this does not mean that the program 
implementation perfectly meets its design requirements. 
The task of analyzing the program to identify and correct 
defects in implementation and design is known as the pro- 
gram test task. On large projects, this is often a very difficult 
process. 

The HP SoftBench environment provides strong support 
for understanding both the structure (with the static 
analyzer) and the behavior (with the program debugger) of 
large, complex applications. 

The program debugger (see box, page 55) provides pro- 
gram execution in a controlled environment. The user can 
step through the program, watching for specific conditions, 
pausing at any time to examine the state of data structures, 
and monitoring the control flow through the various paths 
of the program. If a variable is somehow being set to an 



illegal value, the user can trace the variable to locate the 
conditions and location of the improper assignment. If a 
function is being called when it shouldn't be, the user can 
monitor the execution, watching for the conditions which 
caused this call. 

In analyzing the behavior of complex applications, it is 
often useful to view the execution at lower levels of abstrac- 
tion. The program debugger can simultaneously show the 
program's source code, the assembly code, and the proces- 
sor's register contents. The program debugger can walk 
through the program's execution either at the assembly 
statement level or at the source statement level. 

The static analyzer is often used hand in hand with the 
program debugger. For example, if a variable is being set 
to an illegal value, the static analyzer identifies all locations 
where the specific variable is set, and the program debugger 
can be used to set tracepoints at each of these locations. 

When a problem has been located and a change has been 

(continued on page 56) 
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Program Debugger 



The HP SoftBench program debugger provides a powerful yet 
simple user interlace io the HP-UX symbolic debugger xdb. mak- 
ing users effective in their debugging tasks with a minimum of 
effort We were surprised to learn how many users avoid using 
some HP-UX debuggers because of the difficulty of learning their 
command languages These users would rather resort to some 
of the most tedious and time-consuming methods of tracking 
down simple bugs than master some esoteric tool. 

Other goals for the program debugger were integration with 
the other HP SoftBench tools, provision of added value over the 
standard HP-UX symbolic debugger, and exploration of the po- 
tential for automated use of tools in the future. 

User Interface 

Using the HP SoftBench program debugger, software develop- 
ers can become proficient at common debugging tasks in very 
short order, even if they are not familiar with the standard HP-UX 
debuggers. Pull-down menus and accelerator buttons, along with 
point and select operations with the mouse, provide a very simple 
means for entering powerful debugging commands (see Fig 1 ) 
Almost all of the functionality of the standard HP-UX debugger 
is available via mouse-onenled commands. Many sophisticated 
sequences of commands are also made available with a single 
menu selection When the user must use a more esoteric com- 
mand, It is possible to type it in directly to the HP-UX debugger 

The program debugger extends the user's view of the program 
being debugged by allowing more simultaneous views than stan- 
dard debuggers (see Fig. 2) The user can see program input/out- 
put, debugger input/output, source code, assembly instructions, 
register sets, and even the state of signals being handled by the 
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Fig. 1. Entering program debugger commands. 
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Fig. 2. Multiple views ol program 
execution in the program de- 
bugger. 
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debugger — all at the same lime if desired. Because these views 
are in separate windows, they are not constrained by the same 
space resources as in conventional, terminal-oriented HP-UX 
debuggers. 

One of the most useful features is separation of the I/O streams 
for the HP-UX debugger and the program being debugged into 
separate window panes. This allows the user to see (and re- 
member) what the program is doing without sorting through con- 
fusing debugger commands, prompts, and printouts Each of 
these views is scrollable and editable, allowing the user to review 
and repeat previous entries. 

Added Value 

Since the program debugger is implemented using the HP 
SoftBench distributed support mechanisms, users can debug 
programs on other machines and with distributed source files 
without doing any extra work. The program debugger lakes care 
of starting the HP-UX debugger on the correct machine (the one 
hosting the executable file) and establishes all the necessary 
interprocess communication. While this is not a substitute for 
nonintrusive distributed debugging, it does satisfy the distributed 
debugging needs of many users 

For applications with signal handlers that must be debugged, 
the program debugger has a special window to help the user 
monitor signals that are received, handle each signal specially, 
and send specific signals to the application. All of this can be 
done withoul going to a terminal window and without looking up 
process ID numbers and signal numbers. 

Program debugger users rarely need to know about process 
ID numbers, even when sending signals to their applications or 
when adopting already running processes. The task of remem- 



bering the ID numbers when a process is forked or of looking 
up the process ID number (with /bin/ps) using the program s name 
is handled automatically. 

The standard HP-UX symbolic debuggers give minimal sup- 
port tor monitoring the value of program variables It is possible 
to set up assertions that show the value after each instruction 
executed (slowing execution incredibly), or to set up breakpoints 
to show the value at specific points m the program, but great 
imagination (and tedium) are required to do much more The HP 
SoftBench program debugger allows the user to specify a vari- 
able to be traced and then uses a rather involved set of break- 
points and assertions to implement a primitive but often useful 
variable tracing facility. 

Automated Tool Use 

The HP SoftBench tool integration architecture allows tools to 
communicate with each other by means ol request and notifica- 
tion messages While the current HP SoftBench tools only docu- 
ment a limited set of requests, it is possible for tools such as the 
program debugger to be controlled entirely by a program rather 
than a person For example, tool builders can use the HP Encap- 
sulator (see article, page 59) to construct higher-level tools that 
issue requests to the static analyzer and the program debugger 
These higher-level tools can monitor program data structure re- 
ferences or modifications, perform branch flow analysis, monitor 
performance, or handle dozens of other useful operations. 

Robert A. Morain 
Robert B. Heckendorn 

Software Development Engineers 
Software Engineering Systems Division 



made, it is important to be able to assess the impact of the 
change. For example, if a function needs an additional 
argument, all calls to the function must be located and 
modified, If a function's return value must be changed, all 
locations in the project that use this function's return value 
must be identified and changed. The static analyzer facili- 
tates these activities. 

Program Maintenance 

Program maintenance is similar to program test. Software 
requirements change over time, and modifications may be 
needed to the program for reasons other than defects in 
the program. The programmers who maintain applications 
are often not the original developers and may need assis- 
tance to understand the design and implementation of the 
program so that they can make the necessary modifications 
effectively. These factors make the ability to understand 
the application crucial. In fact, much of what software 
maintenance programmers do is work on understanding 
the applications they maintain and assess the impact of 
proposed changes. While the changes themselves are often 
small, identifying the source of the problem, designing an 
appropriate change, and assessing the impact of the pro- 
posed change is often very difficult and time-consuming. 

The static analyzer and the program debugger are the 
primary tools for helping the maintainer understand the 
application, identify the problem, and assess the impact 
of proposed changes. The program editor and the program 
builder are used to reconstruct the modified application 
and the static analyzer and the program debugger are used 



to test the changes. If the modifications to the application 
caused a change in the module dependencies (for example, 
if a new module was added), then the program builder will 
update its data base of dependencies (the makefile). 

In addition to locating specific conditions in the program , 
the static analyzer and the program debugger help the pro- 
gram maintainer work backwards from the symptom to the 
cause. For example, if the user of an application reports a 
problem when a specific error message is displayed, the 
program maintainer can ask the static analyzer to show r the 
locations in the program where the message is displayed. 
The program debugger can then be instructed to monitor 
those points as the maintainer reconstructs the scenario 
that led to the error message. Once the problem situation 
is duplicated, the maintainer uses the program debugger 
to examine the state of the application and determine the 
function call sequence and data structure state that caused 
the defect situation. 

Conclusion 

We have described how the HP SoftBench environment 
is used to support team file management, team communi- 
cation, program construction, program test, and program 
maintenance. The goal was to illustrate not only the fea- 
tures of each of the HP SoftBench software development 
tools, but to demonstrate the synergy that can be achieved 
by letting the tools collaborate to provide a task-oriented 
software development environment. 

With the HP Encapsulator product described in the arti- 
cle on page 59, common development activities involving 

(continued on page 58) 
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Integrated Help 



The HP SoftBench help facility (see Fig 1 ) is independent ot 
the tools for which it provides help. For efficiency, the help appli- 
cation is combined with the tool manager 

Each tool contains a help pull-down menu containing Hem Help 
and Application Help entries When a user asks for item Help the 
mouse sprite changes into a question mark The user can then 
point at a region of any HP SoftBench application and help text 
describing that part of the tool will appear in the help window 

Each piece of text is displayed with a list of related topics 
Selecting the related topic causes the text for that topic to appear 
The cross references can point to topics inside another tool 

The normal HP SoftBench mtertool communication mecha- 
nisms are used to drive the help system. When a user selects 
Application Help, a request is sent to the help system lo display 
the information The tool is not aware of its own or any other tool's 
help text. 

The help data base and communication between the other HP 
SoftBench tools and the help tool (the item Help lookup mecha- 
nism) require no cooperation from any application as long as it 
is implemented with the HP widgets and the X toolkit (which 
stores the needed properties on the widget windows) The help 
menu items do require minimal cooperation from the application, 
ot course Ideally, dependence on the HP widgets would not 
have been needed, but the information provided by applications 
complying with the Inter-Cltent Communication Conventions 
Manual (see box, page 23) or by the X toolkit (Xt Intrinsics) is 
not sufficient for this level ol detail 



Interface between Tools and the Help System 

HP SoftBench tools communicate with the help system via the 
X protocol and the HP SoftBench broadcast message server 
Requests for item Help and Application Help are sent as request 
messages to the help tool A request for Application Help includes 
the application class of the application, and a request for item 
Help causes the help tool to grab the pointer (changing the pointer 
to a question mark temporarily) For item Help the help tool has 
to figure out which widget was selected This is done without the 
assistance of the specific application as long as the application 
is built using HP widgets. Each widget window stores a property 
xw_CLASS. which contains the widget name and the class of the 
widget window The top-level window also stores the wm.class 
property containing the name and class of the application (as 
defined by the Inter-Client Communication Conventions Manual) 
When the user selects a window, the help tool determines the 
smallest enclosing window containing the pointer and then 
traverses the window hierarchy outward to determine the widget 
namelist and classlist used in a resource specification in the X 
resource manager It looks these up in the help data base to 
locate the help text associated with the help window. This same 
mechanism is used by the automated test facilities described in 
"Architectural Support for Automated Testing" on page 37. 

John R. Diamant 

Software Development Engineer 
Software Engineering Systems Division 
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the HP SoftBench tools can be automated. 
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HP Encapsulator: Bridging the Generation 
Gap 

By means of the Encapsulator description language, a user 
can integrate tools into the HP SoftBench environment 
without modifying their source code, and can tailor the HP 
SoftBench environment to support a particular software 
development process. 



by Brian D. Fromme 

THE HP ENCAPSULATOR is the tool integration and 
process specification facility of the HP SoftBench 
environment. It allows an HP SoftBench user to pro- 
mote existing tools to be fully consistent, integrated HP 
SoftBench tools and to tailor the HP SoftBench environ- 
ment to support a specific software development process. 
The HP Encapsulator provides customization and exten- 
sion capabilities for automating organization, team, and 
personal software development processes using event trig- 
gers, 

Integrating Existing Tools 

The HP Encapsulator can handle a range of existing ap- 
plications. It is designed to handle programs written in the 
style of programs for the UNIX* operating system, that is, 
programs that have a command-line interface to their func- 
tionality. Examples of this sort of program are nearly all 
UNIX tools (tar. prot, adb), customer-developed scripts and 
utility programs, and many third-party tools (e.g.. McCabe's 

'UNIX 15 a registered trademark ol AT&I in the USA and olhor countries 



ACT. Verilog's Logiscope. Softools CCC. and SMDS's Aide- 
de-Camp). 

From the user's point of view, an encapsulated tool looks 
and behaves just as the core HP SoftBench tools do. In fact, 
one of the core HP SoftBench tools is actually an encapsu- 
lation — the HP SoftBench mail tool is an encapsulation of 
the HP-UX tool mailx. This encapsulation will be described 
in more detail later in this article. 

The HP Encapsulator can be used either to add a new 
tool to the HP SoftBench environment or to replace an 
existing HP SoftBench tool or another encapsulated tool. 
The HP SoftBench architecture is designed to facilitate this 
substitution of tools. 

Tool Encapsulation Overview 

Encapsulating a tool means integrating the tool into the 
HP SoftBench tool integration architecture. The HP Encap- 
sulator is the liaison between Ihe existing tool and the rest 
of the HP SoftBench environment. It plays the role of trans- 
lator of commands, actions, and presentation. 



Mailx !• □ 



5 /users/cagan> mailx 

mailx Revision: 64.64 Date: 89/07/24 89:21:98 Type ? for help. 
'Vusr/ma i 1/cagan" : 6 messages 2 unread 

1 claire_phillips%07§hpc680, hpl.hp.com Tue Sep 26 87:39 122/5487 Verilog V 
lsit Report 

2 caganghpfejrd.sde.hp.com Tue Oct 3 17:20 72/2990 Exposing SoftBench In 

tegr 

3 carol_siacotos%a2@hp1908 Fri Oct 6 22:11 48/1337 MAP 

4 ghpfclp.sde. hp. com, gmlrsa . inria . f r : rootgcolumbo . inria.fr Wed Oct 11 82:55 
33/1843 Re: Another try ... 

>U 5 wallckiehpfclk.sde.hp.com Sun Oct 29 12:28 28/998 TEST RESULTS 
U 6 lee_huffman%0e@hp4828 Sun Oct 29 14:55 187/4131 Video Thoughts 
■ I 



Fig. 1. Original user interlace ol 
the HP-UX terminal-based mail 
tool mailx 
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Integrating a tool using the HP Encapsulator provides 
the following benefits: 

■ Provides a link to the HP SoftBench event trigger facility. 

■ Provides an HP SoftBench-compatible, OSF/Motif-style 
user interface (see article, page 6). 

■ Uses HP SoftBench distributed execution to support re- 
mote subprocess execution. 

■ Uses the HP SoftBench network-wide communication 
facility. 

An important aspect of the HP Encapsulator is that no 
source code modifications are necessary to the tool being 
encapsulated. This allows customers to integrate pur- 
chased tools for which no source code is available. 

There are also some limitations of encapsulation that 
should be understood before an encapsulation program is 
attempted. The HP Encapsulator only supports encapsula- 
tion of tools written in the UNIX command-line interface 
model. Tools that have highly interactive or graphical user 
interfaces are often not good candidates for encapsulation 
because the HP Encapsulator cannot understand what the 
tool is doing or has done. User interface potential is also 
limited by output from the encapsulated tool. If the tool 
does not provide error messages or some sort of output 
stream (typically stdout or stderr). the HP Encapsulator is 
constrained in its ability to interpret what the tool has 
done. Another limitation is that event granularity for trig- 
gers and notifications — that is, the level of detail at which 
events can be specified — is only as fine as can be initiated 
and recognized from the encapsulated tool. To achieve the 
same level of event granularity as the other HP SoftBench 
tools, each atomic operation needs a unique command-line 



interface. 

The HP SoftBench Mail Encapsulation 

Before the design details of the HP Encapsulator are de- 
scribed, a sophisticated encapsulation will be presented to 
illustrate the concepts that have been presented so far. 

The encapsulation to be described is the HP SoftBench 
mail tool. This tool is provided with the HP SoftBench tool 
set, and most users are not aware that it is an encapsulation 
rather than a native tool like the other HP SoftBench tools. 
The HP SoftBench mail tool is actually an encapsulation 
of the HP-UX mailx program. The mailx program was not 
modified in any way. 

Fig. 1 shows the original terminal-based interface to mailx. 
and Fig. 2 shows the encapsulation. Before encapsulating, 
mailx was not related or linked to the other HP SoftBench 
tools in any way. The encapsulated version, on the other 
hand, has useful links to the other HP SoftBench tools. For 
example, the user can configure HP SoftBench mail to send 
a mail message to the project team whenever a project build 
has completed successfully. With the HP Encapsulator, 
customers can customize the specific conditions and ac- 
tions to meet their particular needs. 

Other Encapsulations 

Many other tools have also been encapsulated. Fig. 3 
shows the encapsulation of the HP-UX performance profil- 
ing tool prot(i). Fig. 4 shows an experimental encapsulation 
of the Analysis of Complexity Tool for metrics collection 
and structured testing support from McCabe and As- 
sociates. Fig. 5 shows a trigger panel with which the user 
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[X] Delete 


Heply to Author... 
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Reply to All... 
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Message-Id: < 98021 22205 . AA8437B@hpbar . sde . hp. com> 
To : colin@hplsf . sde . hp. com 
Subject: Release Party 
^Status: RO 




There will be a party to celebrate the success of 
the Tower project on Jan 18. 1990. Hope 
you can all be there: 




Place: Cuisine Cuisine 
Time: 8:86pm 
Date: January 18, 1990 
Attire: Black Tie 




RSVP Requested. 




Janet 





Fig. 2. User interlace of the HP 
SoftBench mail tool, an encapsu- 
lation of mailx. 
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Fig. 3. Encapsulation of the HP-UX performance profiling 
tool prof. 

can configure the relationship between the McCabe testing 
tools and the rest of the development environment. 

Prototype encapsulations have been written for config- 
uration management, documentation, testing tools, and 
language-based environments such as Lisp and Ada. 

Encapsulates Description Language 

The Encapsulator description language (EDL) is a 
specification language designed to simplify the task of de- 
scribing an encapsulation. The primary reason for encap- 
sulating a tool into the HP SoftBench environment is to 
allow that tool to make use of the HP SoftBench architec- 
ture, primarily the broadcast message server and aspects 
of the distributed environment. Therefore, these architec- 
tural features have been made accessible in EDL. 

From the perspective of the encapsulation system, there 
are two main components in an encapsulation: interfaces 
and actions. Interfaces are connectors to the outside world, 
such as the window system or the HP SoftBench message 
system. Actions are the steps to be taken when certain 



conditions are met on an interface. EDL defines a set of 
interfaces and data types that link conditions in an interface 
to actions that the user provides to respond to that condi- 
tion. The actions are EDL code to be executed. 

EDL has conventional programming language constructs 
such as data types, variables, operators, flow-of-control 
clauses, and user-defined functions. EDL also contains a 
rich set of built-in functions, which provide a programmat- 
ic interface into the HP SoftBench architecture as well as 
the underlying window system. The EDL data types are 
string, integer. Boolean, attribute, event, and object. There 
are C-like operators that can be used to form expressions. 
There are two flow-of-control clauses: it and while. User-de- 
fined functions can be used to group and define parameters 
for EDL statements, but are most useful as actions for re- 
sponding to conditions. 

A programmer develops EDL code much as one would 
develop code in other specification-language-based envi- 
ronments, that is, by first entering the EDL source text into 
a file, then invoking the HP Encapsulator over that file. 
See page 67 for a description of how the HP Encapsulator 
executes the EDL code. 

Interfaces 

Four interfaces are defined in the Encapsulator descrip- 
tion language. They are the user, message, application, and 
system interfaces. The user interface is the window system, 
the message interface is the HP SoftBench broadcast mes- 
sage server, the application interface is the encapsulated 
program or subprocess. and the system interface is the 
operating system. Conditions on an interface are called 
events. 

An event is a data type in EDL. Events have three com- 
ponents, a type, a pattern, and an action. The type defines 
the interface to which an event corresponds. The type 
specifier is the identifier or the name of the interface. Thus 
the user interface has events of type user. The pattern is 
the condition to be met on an interface. A pattern is a string 
that identifies either the name or the form of a condition. 
For example, application events use the HP-UX regular 
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Fig. 4. Encapsulation of the Analysis of Complexity Tool 
(ACT) from McCabe and Associates 
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Fig. 5. Triggers for the encapsulation of McCabe s ACT 
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expression pattern matching facility, so the pattern is a 
string that describes a regular expression to that pattern 
matcher. 

An example should help clarify how an event is declared. 
This event will occur when the encapsulated program mailx 
finds that there is no new mail available. 

First, we declare an event variable. 

event mailx_event: 

Now we assign that variable a newly created application 
event. The event corresponds to the condition that mailx 
has written the text "No mail for Fromme" to stdout (its 
standard output file). 

mailx_event = make_event(Application. "No mail lor (.')$0\n", 
no_mail($0)); 

Finally, we add this event into the list of active events. 
add_event(mailx_event): 

Events can be activated and deactivated via built-in func- 
tions in EDL. This allows the user to control which condi- 
tions can be met at a given time. When an event is defined 
in the user interface, that event must correspond to a par- 
ticular object in the window system. EDL objects will be 
explained in more detail later. 

Actions 

Actions are the steps to be taken when certain conditions 
are met on an interface. In the example above, the action 
to be taken when the regular expression is matched is a 
call to the function no_mail(). Actions can be arbitrary state- 
ments of EDL code. In use. however, actions are typically 
calls to functions that are defined by the user. This makes 
the declaration of an event more readable and more easily 
changed or configured. 

For example, we will define the function no_mail(). which 
is to be called when the HP Encapsulator sees the no-mail 
pattern from mailx. Note that the argument passed to the 
no_mail() function from the event is $0. This is the EDL 
syntax for the special string variables that retrieve portions 
of a regular expression. In this case, $0 will be the name 
of the user running the SoftBench mail tool. 

/'This function is called when mailx tells us there is no new mail */ 
function no_maii(user) 
string user; 

{ 

r Let the user know that there is no new mail in the mailbox 7 
clear(headers); I" Clear mail headers lis! ' 

freeze_buttons(); '* Make the burtons insensitive * 

■ This is a local string variable that holds the dialog prompt ' 
string info = pnnt_to_string("User %s has no new mail", user); 

" Now pop up the dialog box to inform the user 1 
errorflnformation. Info); 

r No need to return data from this function ' 

i 



Notice that the action function calls other functions, 
some of which are built-in EDL functions and some of 
which are user-defined functions. This example shows how 
we have taken a condition from the terminal based mailx 
application and turned it into an information dialog box 
via a call to the built-in EDL function error(). 

User Interface 

The user interface is the window environment in which 
a user can interact with the encapsulation. Components of 
the user interface are referred to as objects. An object is 
any visual device that conveys information between the 
user and the program — examples are labels, buttons, 
menus, and editable fields. An object is also a data type in 
EDL. Objects are EDL representations of physical entities 
on the screen. There are two types of EDL objects: manager 
and primitive. Manager objects can control other objects 
while primitive objects cannot. The set of EDL manager 
objects includes Toplevel. Transient. Pulldown, and Pane, while 
the set of EDL primitive objects includes MenuButton, 
MenuSeparator, Command, Label, Edit. List. Toggle, and Image. 

To define a user interface in EDL, one specifies the hierar- 
chy of manager and primitive objects that compose each 
window as EDL statements. The following example will 
create a window with two objects, a Label object and an Edit 
object. 

First, we declare the window and its first pane, both of 
which are manager objects. 

object maiLwindow - make_manager(NULL, Toplevel. 
"MailWindow"); 

object pane = make_manager(mail_window. Pane, "firstPane"); 

Now we declare the components of the pane, both of which 
are primitive objects. 

object targeLlabel = make_object(pane. "target". Label, 
"Target: "); 

object targeLvalue = make_object(pane, "value", Edit. 
get_context_file()); 

In this example, the elements of a Toplevel window have 
been described. Manager objects are declared with the 
built-in EDL function make_manager(). while primitive ob- 
jects are declared with the built-in EDL function make_ob- 
ject(). The parameters of these built-in functions describe 
information about how to create such an object when the 
time comes, such as the parent (or manager) of this object, 
the name, the type, and the label (or initial value to be 
displayed within the object). Objects described in this way 
are not created until their entire window is needed. This 
is achieved via a call to the built-in EDL function display!). 

To take an action in the user interface, the user often 
presses the left mouse key (mapped to the Select action) 
while the mouse cursor is over the object that describes 
the action. To define the action in EDL. the programmer 
must associate a user event with a user interface object. 
Thus, each user interface object is associated with distinct 
events or actions. Several objects can be associated with a 
single event. The following example creates three Toggle 
buttons and two events. A Toggle button is a user interface 
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object that represents either an on or an off state. The two 
events are used to determine when the user turns the button 
on and off. 

First, we create two events that trigger actions for any of 
the three Toggle buttons. 

event toggle_on =» make_event(User. Select". toggle(True)); 
event toggle_ofl ■ make_event(User, "Release". toggle(False)); 

Then we declare three Toggle button objects. 

oD|ect a. b. c: 

Notice that we pass both events to each of these objects. 

a = make_object(pane, "a". Toggle. Me". NULL. toggle_on, 
toggle_off); 

b = make_object(pane, "b". Toggle. "Myself". NULL, loggle_on. 
toggle_off); 

c = make_object(pane. "c". Toggle, "I". NULL, toggle_on. 
toggle_off): 

This function handles both the on and the off states for 
these Toggle buttons. 

function toggle(on) 
boolean on; 

I 

/* Gel the object with which this event is associated */ 
object this.button ■ self(); 

/* If we selected one of these buttons, then release the 
• others. This makes the buttons exclusive (only one can 
' be set at any given time). 7 

it (on) | 

r Send the "Release" event to all buttons but this one V 
if (thisjwtton != a) send_event(a, toggle.ott); 
It (this .button ! ■ b) send_event(b. toggle.off); 
if (thlsjjutton ! - c) send_event(c, toggle_off); 

I 

I 

This example defines a window object and its action. 

Another aspect of the user interface is the appearance of 
an object, such as width, height, color, and character font. 
In EDL. these characteristics of an object are referred to as 
attributes. An attribute is a data type in EDL. There are 
two attribute operators: merge and associate. The merge 
operator is used to combine a single attribute into a set of 
attributes called an attribute list. The associate operator is 
used to combine a value with a named attribute. As can 
be seen in the following example, the WIDTH attribute allows 
an associated value, while the SINGLELINE attribute does 
not. The example illustrates the creation of a single-line, 
labeled, editable field of a certain width. 

object label, edit; 
attribute attr; 

The following attribute merges a font description with a 
specified width and also tells the Label object to put the 



text as far left as possible. 

attr = FONT . "hp8x16" | WIDTH ; 100 I LEFTJUSTIFIED: 
label = make_ob|ect(pane. "dirLabel". Label. "Directory:", 
attr). 

The following attribute merges a font description with a 
specified width and also tells the Edit object to restrict its 
view to a single line. 

attr - FONT : 'hp8x16" | WIDTH : 300 SINGLELINE; 
edit = make_ob|ect(pane. "dirValue". Edit. 
get_context_directory(). attr); 

Attributes are used to specify the appearance and be- 
havior of user interface objects. The example above shows 
their static use, that is. to specify the object's behavior 
when first displayed. Attributes can be used dynamically 
through the EDL built-in function add_attribute(). This allows 
the appearance of an object to change during execution of 
the encapsulation. 

Message Interface 

The message interface is the programmatic access to a 
tool's functionality. This interface is the connection to the 
broadcast message server and allows tools to communicate 
with one another, just as a user would interact with a tool 
through the user interface. The messages that a tool can 
emit and receive define the tool's message protocol. The 
HP SoftBench tools have a predefined message protocol. 
When a user encapsulates a tool, a new message protocol 
is defined. This protocol is called the tool class. 

To define a new tool class, one must decide what func- 
tionality of the new tool should be accessible to other tools. 
Most often this is the same functionality that is available 
to the user via the user interface. Next, the developer must 
decide how other tools are to be passed information specific 
to each tool function. Typically, information that the user 
interface receives by bringing up a dialog box can be re- 
ceived in the message interface as the data fields of a mes- 
sage. 

There are several requirements that should be met for a 
new tool class to become a "good citizen" HP SoftBench 
tool. A notification message must be announced whenever 
the tool successfully performs a function. A failure message 
must be announced whenever the tool attempts to perform 
a function, but does not successfully complete it. A request 
message must be accepted for each function thai the tool 
is able to perform. 

The message model allows tools to request other tools 
to attempt to perform functions. Furthermore, because tools 
send out notification or failure messages after attempting 
to perform a function, a tool can determine the results of 
such a request. Thus, tool interaction can be either synchro- 
nous or asynchronous. For example, a tool may request 
that an edit of a particular file be started, but may not care 
whether the editor can actually perform the task. On Hie 
other hand, if a tool requests that a file be checked out of 
the version control system, it will need to know whether 
that function can be performed before continuing with the 
current operation. 
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To facilitate handling arbitrary requests, the broadcast 
message server defines a simple pattern matching facility. 
This facility is accessible through the EDL built-in function 
make_message_pattern(). When message events are defined, 
the message patterns will be passed to the broadcast mes- 
sage server. These describe the forms of messages to be 
forwarded to the HP Encapsulator. 

The following example describes the message interface 
for the simple tool class EXAMPLE. 

/• Define the tool class '/ 
tooLclass("EXAMPLE"); 

These are variables used in the message interface. 

string pattern; 
event plan, estimate; 

This describes the PLAN request message. 

pattern ■ make_message_pattern(Request, NULL, "PLAN"); 
plan = make_event(Message. pattern, plan_request()); 

This describes the ESTIMATE request message. 

pattern = make_message_pattern(Request, NULL, "ESTIMATE"); 
estimate = make_event(Message, pattern, estimatejequest()); 

Now we activate these events. 

adcLevent(plan); 
add_event(estimate) ; 

These are the functions for the PLAN and ESTIMATE mes- 
sages. The PLAN message takes two data parameters: the 
name and the engineer-months. The ESTIMATE message 
takes no data parameters. 

(unction plan_request() 

f 

string name, months; 

/' Extract and check the data parameters V 
name = message_data(1); 
months = message_data(2); 

" If these aren't passed, then its an error 7 
if (Iname j Imonth) protocoLerror(); 

else 

/" Perform the PLAN request V 
if (planfname, month)) 
■ Succeeded 7 

send_message(Notify, NULL. "PLAN", name, months); 
else 

• Failed */ 

send_message(Failure, NULL, "PLAN", name, months); 

} 

function estimate_request() 

I 



r Perform the ESTIMATE request 7 
if (estimate')) 
■ Succeeded '< 

send_message(Notify, NULL, "ESTIMATE"); 
else 

/• Failed V 

send_message(Fallure, NULL, "ESTIMATE"); 

I 

In this example, we have declared a tool class EXAMPLE 
and registered two patterns with the broadcast message 
server, each of which has a function to handle the request 
when the corresponding message is forwarded to the HP 
Encapsulator. The functions check that each message has 
the appropriate data and call other functions to attempt 
the requested action. If the actions succeed, then a notifi- 
cation message is sent to the broadcast message server. 
Otherwise, a failure message is sent. 

By knowing the message protocols of a tool, one can use 
the HP Encapsulator to: 

■ Create a tool that interacts with other HP SoftBench tools. 
« Create a tool that drives other HP SoftBench tools. 

■ Createa tool that replaces an existing tool (substitution]. 

■ Create agents. Agents are tools that orchestrate other 
tools to perform tasks. 

Tool Triggers 

A trigger is a cause-effect relationship between tools. In 
the HP SoftBench environment, a trigger occurs when a 
notification or failure message is sent from one tool and 
one or more other tools respond to that notification by 
taking some new action. For example, when a file is saved 
from any tool, the HP SoftBench development manager 
tool will update its directory listing, if needed. This is a 
predefined trigger in the HP SoftBench environment. 

The HP Encapsulator allows the user to define two types 
of triggers; those that take action in a tool and those that 
request some third tool to take an action. The HP SoftBench 
development manager example above is a trigger that takes 
action in a tool. The following code is an example of a 
trigger that requests a third tool to take an action. It listens 
for a notification message from the development manager 
and asks the HP SoftBench program builder tool to attempt 
a build. 

When we see a VERSION-UPDATE-DIR message notification, 
send out a BUILD-TARGET request. 

event tngger; 
string pattern; 

This pattern and event describe the message to be seen. 

pattern - make_message_pattern( Notify. "DM". 

"VERSION-UPDATE-DIR"'); 
trigger = make_event(Message, pattern, requesLbuild()); 
add_event(trigger); 

This function requests that a build be started when an 
update of the version directory is done in the development 
manager. 
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HP Encapsulates CASE Case Study 



Frederick Brooks wrote: "Plan 10 Ihrow one away, you will, 
anyhow The day before the U.S.A. announcement and dem- 
onstration of the HP SoftBench environment, we threw away the 
mail tool Work began immediately to rewrite it almost completely, 
using ideas we had learned from the previous effort This time, 
instead of writing an entirely new mail program, our approach 
was to use the HP Encapsulator to encapsulate the HP-UX mail 
program maiix 

Why Another Mailer? 

There were several reasons for writing yet another mail pro- 
gram: 

■ Provide a bridge from HP SoftBench messages to mail mes- 
sages When a particular HP SoftBench message is sent, a 
software developer might want to send mail to notify the team, 
the developer, or others. This would be especially true for 
processes that run unattended or at night. 

o Improve the user interface Most mailers that run under the X 
Window System have a human interface best described as 
nonideal. Some confuse new users with clutter, some require 
a lot of customization, and some are hard to maintain in a 
changing environment HP SoftBench mail tries to provide a 
better user interface 

« Teach the HP Encapsulator language by a nontrivial example. 
We wanted future developers to learn advanced techniques 
by studying the code and its comments. 

■ Fine-tune the HP Encapsulator. The new technology of the HP 
Encapsulator needed to be used to get it ready for commercial 
use 

■ Improve the usefulness of the HP SoftBench environment. 
Studies show that technical users buy a computer to solve 
important or costly problems like software development, not 



function requesLbuild() 

< 

f convert a wildcard for directory to a nil */ 

string mfile = messagejile(); 

if (string_compare(mfile, """)) mfile = /* Message 

" server nil V 

. ' Get the current context *,' 
host i get_contexLhost(): 
dir = get_context_directory(); 

/' Now set the context from the incoming message 7 
set_context(message_host(), rnessage_directory(), mfile); 

/' Send the request to the BUILD tool class */ 
send,message(Request, "BUILD", "BUILD-TARGET", "-", "-", '•-"); 

) 

The ability to define triggers allows the user to customize 
the HP SoftBench environment lo meet process-specific: 
needs. The following section describes the benefits of user- 
definable triggers. 



for office automation tasks like mail Nevertheless, they expect 
the manufacturer to provide a mail system 

Using the Encapsulator 

The Encapsulator description language (EDL) is a new lan- 
guage A new language allows one to sail the seas of new higher- 
level ideas, explore uncharted waters of new constructs, and 
breeze past the rocks of low-level details so prominent in such 
libraries as the X toolkit. However, new languages usually include 
a new paradigm — a new way of thinking about the programming 
problem. This is certainly true for EDL. 

Encapsulating a complex tool like the HP-UX maiix application 
has its challenges, too. As we progressed on the rewrite, we 
learned more about maiix that caused us to modify our design. 
For instance, the code to manage folders was rewritten twice as 
we learned subtle interactions m the way that maiix handles fold- 
ers. Even though we did have access to the source files for maiix. 
we looked at them only once — to discover that we couldn't find 
the answer in the code! It turned out to be much easier simply 
to set up conditions, run maiix in a terminal window, and observe 
its behavior. On the other hand, encapsulating an existing pro- 
gram is code reuse at its best. Someone else had already solved 
hard problems of mail delivery, folder management, alias crea- 
tion, message presentation, and so forth. To paraphrase Isaac 
Newton, HP SoftBench mail sees farther than its predecessors 
because it is standing on the shoulders of the giants that already 
provided part of the solution. 

Bob Desinger 
Software Development Engineer 
Software Engineering Systems Division 



Process Integration 

One of the promising new areas in software engineering 
environment research has to do with providing automated 
support for the user's software development process. The 
HP Encapsulator is one of the first products to provide a 
language for describing local organizational, team, and per- 
sonal processes. We refer to an EDL program that supports 
a user's development process as a process specification, 
and we refer to this type of environmental support as pro- 
cess integration. 

Process Specifications 

While not all development processes are amenable to 
being described with EDL process specifications, most can 
have at least some aspects automated. In particular, activ- 
ities and tasks that are essentially event-driven are prime 
candidates for automated support. 

The author of an EDL process specification tells the HP 
SoftBench environment what to do when specific events 
occur. There are two keys to the successful implementation 
of EDL process specifications. First, the notification mes- 
sage events must be announced so that the proper actions 
can be triggered by the EDL process specification. All HP 
SoftBench tools and all properly encapsulated tools issue 
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these notification messages. Second, when a trigger in an 
EDL process specification occurs, the resulting action 
needs to be able to control other tools in the environment. 
All HP SoftBench tools and all properly encapsulated tools 
provide this by means of the message-based interface to 
their functionality. 

As an example of an EDL process specification, the fol- 
lowing team process could be automated: 

■ Whenever a team member checks a file into the master 
source file repository (directly or indirectly through the 
development manager or a substituted configuration 
management system supporting the DM versioning com- 
mand class), with a state having the value Release, cause 
complexity metrics to be calculated. 

■ If the complexity metrics for the file are not acceptable 
as defined by the team, create a metrics report detailing 
the unacceptable functions, and mail it to the user. Also 
notify the user of the problem via a Warning notification 
box. 

I If the complexity metrics for that file are acceptable, 
cause a tape archive to be created. 

■ When the tape archive has been successfully made, cause 
a mail message to be sent to the project team announcing 
a new release. 

It is important to realize that each team member may 
have slightly different versions of the above specification, 
for very legitimate reasons. For example, a software quality 
assurance engineer team member might want to lake action 
when a metric is found to be unacceptable. 

Linking Events and Actions 

Linking HP SoftBench Tools. Every action of every HP 
SoftBench tool provides the hook needed for that action 
to act as a trigger for other actions. By default, certain 
actions are predefined, such as the view synchronization 
that causes tools to know when the files they are displaying 
become out-of-date so that the user can be informed. With 
the HP Encapsulator, the user can define additional triggers 
for situations where actions need to be automatic. For 
example: 

■ When a file is checked out. cause the editor to display 
it automatically for editing. 

■ Cause a file to be checked in whenever it has been saved 
from the editor. 

■ Cause a build to be initiated whenever a file is checked 
in. 

■ Cause the debugger to reload automatically whenever a 
build is successful. 

■ Cause the static analyzer to update its data base 
whenever a build is successful. 

Linking HP-UX Tools. The HP Encapsulator can be used 
to encapsulate and link UNIX tools. For example: 

■ Encapsulate the tape archiver (tar) and cause tape back- 
ups to be made whenever a release is built. 

■ Encapsulate the job scheduling commands (at or cron) 
and cause builds to run at night. 

■ Encapsulate the source analysis program (lint) and cause 
it to analyze a file automatically when it has been 
checked into version control or saved from the editor. 

■ Encapsulate the source file printing programs (pr, Ip) and 
cause listings to be printed whenever a project release 



is made. 

■ Encapsulate the performance display programs (prof, 
gprof) and cause the performance data to be displayed 
after the program has been executed. 

■ Encapsulate the symbol searching program (nm) to iden- 
tify libraries that must be added to the library list when 
the linker finds symbols it cannot resolve. 

■ Encapsulate the control flow program (ctlow) and cause 
the output to be displayed whenever a file is checked 
into version control. 

Linking Local Tools. After visiting several large customer 
installations and presenting the ideas and capabilities of 
the HP Encapsulator. it became clear that an important 
source of tools to encapsulate and processes to automate 
would be local tools developed on site. Examples of some 
of the more common encapsulations and process specifica- 
tions are: 

■ Encapsulate local metrics collection tools and cause 
them to process the files when they have been checked 
into version control. 

■ Depending on the nature of the local project management 
tools, cause them to do their processing whenever a re- 
lease is made or when a file is checked in. 

■ Depending on the precise capabilities and structure of 
the defect tracking mechanisms, cause the defect resolu- 
tion component to prompt for its data whenever a new 
local build is successful or whenever a file has been 
checked out or in. 

Linking Target Machines. When developing for a remote 
target machine, there is typically a great deal of manual 
intervention involved in transferring the application to the 
target computer and building and testing it there. Assuming 
there is some basic file transfer and remote job entry capa- 
bility from the host to the target system, then using the 
remote execution capability of the HP SoftBench environ- 
ment and the Encapsulator, the cross-development process 
could be improved as follows: 

■ Whenever a file is checked into version control on the 
development system, cause it to be copied automatically 
to the remote target. 

■ When a build is requested, optionally cause it to execute 
on the target computer (typically running make or any 
local compile mechanisms, such as a batch job). 

■ Encapsulate the job control facility on the target system 
and cause builds and tests to be run there, initiated from 
the local system. 

■ Encapsulate any test scaffolding on the target system and 
run tests of the application on the target system under 
the control of the local development machine. 

■ Encapsulate any performance measurement facilities 
available on the remote target and monitor performance 
behavior remotely. 

Linking Events with People. Perhaps the most important 
form of link is the connection between people — individuals 
and the team — and important events. The definition of an 
important event likely varies as the development project 
progresses. This is why the ability to change this definition 
frequently and from user to user is an important capability 
of the HP Encapsulator. Some typical triggers for coordinat- 
ing teams are: 

■ Send mail to the project leader when files are checked 
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out. 

■ Send mail to the project team when a new version of a 
common include file is checked in. 

■ Send mail to the project team when a successful system 
build completes. 

■ Send mail to the project team when a system buiJd fails. 

■ Send mail to the project team when a new release is 
made. 

■ Send mail to the project team when weekly static 
analysis data is available. 

■ Use encapsulated write(l) or taik(l) to initiate interactive 
discussion of changes when an include file is checked in. 

■ Initiate an announcement tool (e.g.. news or notes) to 
inform the team of a new release. 

Process Specifications in the Future 

The examples given above show the types of process 
specifications that can be designed to assist with software 
development tasks and to link tools, computers, and 
people. 

EDL process specifications are among the most interest- 
ing applications that exploit the HP SoftBench tool inte- 
gration architecture. The technology is quite new. More 
data needs to be gathered on the lypes of EDL process 
specifications that users write and how much of their pro- 
cess they wish and are able to automate. 

Languages in general are difficult to design. Special-pur- 
pose specification languages are often more difficult since 
they are breaking new ground and trying to express new 
ideas. EDL is a language used for specifying both tool en- 
capsulations and process specifications. However, its de- 
sign leans towards expressing those concepts necessary for 
integrating a tool. In certain cases it feels awkward writing 
a process specification with EDL. Language design for pro- 
cess specification languages is a current research topic 
being pursued at several university and industrial research 
labs and ongoing progress in this area is sure to be seen. 

HP Encapsulator Implementation 

The Encapsulator description language is a special-pur- 
pose specification language. It is implemented by means 
of a compiler and an interpreter. The compiler is responsi- 
ble for parsing an EDL input file and generating inter- 
mediate code. The interpreter is responsible for the execu- 
tion of that intermediate code. The HP Encapsulator is the 
development environment for producing EDL code. The 
HP SoftBench environment contains a portion of the HP 
Encapsulator, which is the run-time environment for 
executing compiled EDL code. This allows HP SoftBench 
and the HP Encapsulator to be two separate products. Users 
wishing to develop EDL code can do so with the HP Encap- 
sulator and can deliver the production EDL code in binary 
form to any HP SoftBench system. 

Compiler 

The compiler is responsible for generating intermediate 
code from the user's source file or files. It does this in two 
passes. The first pass is an invocation of the C preprocessor 
over the EDL source file. This allows the programmer to 
make use of C preprocessor constructs such as macros, 
include files, and conditionally compiled code. The second 



pass invokes a parser over the preprocessed source code. 
The parser scans the input source code into tokens, recog- 
nizes and stores symbols, and forms productions. Produc- 
tions are groups of tokens that form an EDL statement. 
When a production is formed, intermediate code can be 
generated. The scanner and parser were produced from the 
HP-UX tools lex and yacc. respectively. These tools accept 
descriptions of tokens and grammars and generate the 
source code for the scanner and parser components. 

Symbols are identifiers such as variable names within 
the source program, and are stored in the symbol table. 
The symbol table is used to record information about each 
symbol, such as its type, value, printable name, and func- 
tion address, and whether it represents a function. Because 
there are often many symbols in an EDL program, a hashing 
algorithm is used to make symbol lookup more efficient. 

Intermediate code is generated by the compiler and 
stored in the statement table. The statement table has three 
components: the tag. the head, and the tail. The tag iden- 
tifies the current instruction or operator. The head and tail 
refer to the left and right operands of the current instruc- 
tion, respectively. The following is an example of the code 
generated by the simple EDL statement, "assign the variable 
X the value Y plus 10." 

r Here are the declarations ot the integer variables. These 

• two symbols are stored in the symbol table. No code is generated 'I 
integer X, Y; 

/• Here's the assignment statement for which code is generated 

• (below)'/ 

X = Y + 10; 



Table I 

Intermediate Code Stored in Statement Table 



Tag 
(1) Symbol 



Head 



Symbol Index of X 

(2) Symbol Symbol Index of Y 

(3) Integer Constant 1 0 

(4) Plus Pointer to stmt 2 



(5) Assignment 



Pointer to stmt 1 



Tail 

NULL pointer 
NULL pointer 
NULL pointer 
Pointer to stmt 3 
Pointer to stmt 4 



Table II 

Identifier References Stored in Symbol Table 



Name 

Po i titer to X 
Pointer to Y 



Type 

Integer 
Integer 



Value 

0 
0 



Function 

None 
None 



Table I is the statement table representation of the inter- 
mediate code generated from the assignment example. The 
intermediate code organization and symbol table were 
modeled after interpreters for lambda calculus languages.' 
The variables referenced in this example have their symbol 
table indexes stored in the symbol table, as shown in Table 
II. These indexes are returned from the hashing algorithm 
during parsing and allow fast variable value lookup and 
assignment during evaluation. 
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Interpreter 

The interpreter is responsible for the execution of inter- 
mediate code. The interpreter is referred to as a recursive 
evaluator because it looks at the tag of a statement in the 
statement table and then calls itself (recursively) to evaluate 
both of its operands (the head and the tail). The result of 
calling the evaluator is a typed value. That value can be 
used as part of an expression or statement. Here is the 
pseudocode for the evaluator: 

/" Pseudocode tor the recursive evaluator, called eval() 7 
procedure eval( statemenLpointer) 

/* eval() takes a single argument, a pointer to a new statement "/ 

! 

P For each operator there is a particular section ot 
"evaluator code '■/ 
switch (on tag of statement) ( 

case OPERATOR1 : 

/* Code specific to handling operatorl ... 7 
break; 

case OPERATOR2: 

/" Code specific to handling operator^ ... 7 
break; 

/" and so on for all operators */ 

| /" End of operator specific handling code 7 

/* Now return the result of the operation 7 
return result; 

} 

Each case of the evaluator has code specific to executing 
the specified operator. If that operator has operands, they 
will be stored in the head and tail of the current statement. 
In the example described above, the assignment operator 
has two operands. The head is the left-hand side of the 
assignment statement, which is the variable reference in 
which to store the result of the assignment. The tail is the 
right-hand side of the assignment statement, which is Ihe 
expression Y + 10, itself a separate operation in the state- 
ment table. 

Other Components 

Other essential components of the HP Encapsulator im- 
plementation include the broadcast message server, event 
handler, and pattern matcher interfaces, the EDL built-in 
functions, the compile-time and run-time stacks, and the 
dump/load facility. 

Of these components, the dump/load facility has the most 
significant product implications. This facility allows the 
developer to compile an EDL program into a binary format. 
This has two effects. It makes the subsequent loading of 
the EDL code much faster and it allows the HP Encapsulator 
to have a run-only version. This run-only version is bun- 
dled into the HP SoftBench product. Thus, an EDL de- 
veloper can use the Encapsulator to implement an encap- 
sulation program and can deliver that encapsulation to any 



HP SoftBench installation. The run-only version of the HP 
Encapsulator is implemented by removing the code mod- 
ules that handle source code parsing, adding an inter- 
mediate code relocation module, and restoring code from 
a file into tables in memory that the HP Encapsulator can 
interpret. The term relocation refers to the task of relocating 
an address in the code file into an address in memory. 
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Introduction to Particle Beam LC/MS 



Particle beam liquid chromatography I mass spectrometry 
(LC/MS) yields classical, library-searchable electron impact 
spectra for compounds that are too thermally labile or 
nonvolatile to be analyzed by gas chromatography I mass 
spectrometry (GC/MS). 

by James A. Apffel, Jr. and Robert G. Nordman 



AMASS SPECTROMETER (MS) is an analytical instru- 
ment that is used to measure the molecular weights 
and chemical structures of molecules introduced 
into it. Samples are first ionized, and then the charged 
fragments are separated and analyzed according to their 
mass-to-charge ratios. HP makes quadra pole mass spec- 
trometers, which accomplish this separation using a quad- 
rupolar electrostatic field. 

The ionization method determines the nature of the frag- 
mentation of the molecules. So-called soft ionization 
causes less fragmentation and hard ionization causes more. 
Electron impact [EI) ionization, a hard ionization technique, 
has evolved as the most useful technique, especially for 
getting information on the structure of the molecule. When 
the electron energy is controlled, the resultant fragmenta- 
tion is extensive, thus elucidating the structure of the 
molecule. The process is also quite reproducible. The mass 
spectra that result can be compared to spectra stored in a 
library and thus used to identify the compound being 
analyzed. 

Chemical ionization (CI) is a softer ionization technique 
than El. It is often used when EI fragments the molecule 
to the point where little or no unfragmented molecules are 
left and thus the analysis will not yield the molecular 
weight of the compound. CI spectra do not contain suffi- 
cient fragmentation information to be library-searchable. 

In addition to identification, mass spectrometers are also 
used for quantitation down to very small concentrations — 
parts per million and sometimes parts per billion. 

Many samples of interest are not single compounds but 
are mixtures of compounds. Examples are metabolytes in 
a biological sample or the seepage from a toxic waste dump. 
Before the mass spectrometer can do its job. the sample 
must be separated into individual compounds. This separa- 
tion is accomplished using a gas chromatograph (GC) or a 
liquid chromatograph (LC). Both types of instruments are 



produced by HP. In a gas chromatograph the sample is first 
vaporized and then separated into its components as they 
are carried by a gas stream. This gas stream can then be 
introduced directly into the mass spectrometer and each 
compound in the mixture analyzed as it enters. This com- 
bined technique is known as GC/MS. 

Many compounds are not volatile enough to be readily 
changed into the gaseous state without decomposing. With 
mixtures containing these relatively involatile and ther- 
mally labile compounds an LC is usually the separation 
instrument. In an LC the compound mixture is dissolved 
in a suitable solvent such as water or methanol and then 
separated into the individual compounds. 

A problem is that this liquid stream cannot be introduced 
at normal LC flow rates directly into the mass spectrometer 
without overloading the vacuum system. Even if this were 
not a problem, the liquid would have to be evaporated and 
the solvent pumped away before the ionization would be 
possible. Various techniques have been tried over the years 
to solve this dilemma. With the moving belt interface,' the 
liquid is deposited on a moving belt, which carries it 
through a desolvation stage and finally into the mass spec- 
trometer. With the direct liquid introduction interface, 2 a 
portion of the LC flow is nebulized directly into the mass 
spectrometer. While the moving belt interface can be used 
in a variety of ionization modes which generate a range of 
analytical information, mechanical and thermal limitations 
make operation difficult and problematic for compounds 
of limited volatility or stability. Although direct liquid in- 
troduction shows improved capability with respect to ther- 
mally labile compounds, the technique generates only 
chemical ionization spectra with the reagent gas limited 
to HPLC (high-performance liquid chromatography) mobile 
phase components. HP has made a direct liquid introduc- 
tion product in the past. 

None of these earlier techniques has earned liquid chro- 
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matography/mass spectrometry (LC/MS) the relatively 
broad and routine use now enjoyed by GC/MS. More re- 
cently, thermospray LC/MS 3 has been introduced and is 
gaining in use. This interface requires the use of an addi- 
tional chemical in the liquid stream which, when the liquid 
is nebulized in a thermal nebulizer, causes charged droplets 
to be formed which eventually become ions. A portion of 
this stream is then sampled by the mass spectrometer. HP 
now offers thermospray LC/MS as an option on the HP 
5988 A Mass Spectrometer. This technique significantly im- 
proves both ease of use and the ability to analyze thermally 
unstable or nonvolatile compounds, but spectral informa- 
tion is still limited to CI spectra. Furthermore, thermospray 
also suffers from problems with quantitative performance 
and analytical predictability. The combination of thermo- 
spray LC/MS and tandem mass spectrometry, or MS/MS, 
offers improvements in the generation of structural informa- 
tion, but MS/MS is costly and the spectra lack sufficient 
reproducibility to be used in computer-based spectral li- 
braries. 

Particle Beam LC/MS 

Particle beam LC/MS is a new approach to interfacing 
high-performance liquid chromatography and mass spec- 
trometry. It yields classical, library -searchable electron im- 
pact (EI) spectra for compounds that are too thermally labile 
or nonvolatile to be analyzed by GC/MS. Particle beam 
LC/MS can also be used in chemical ionization (CI) mode 



with free choice of reagent gases. This versatility, in com- 
bination with ease of use and good quantitative perfor- 
mance, means that particle beam LC/MS is a viable alterna- 
tive, or in some cases a complement, to existing LC/MS 
interfaces. Although particle beam LC/MS is a relatively 
new technique, it has great potential because it satisfies 
the two major trends in LC/MS development described 
above: it is applicable to a wide range of compounds with 
low volatility or thermal stability and it generates high-in- 
formation-content EI spectra. 

Hewlett-Packard's system for particle beam LC/MS is 
shown in Fig. 1. It uses existing HP LC, MS. and data 
systems and a special particle beam interface mounted be- 
tween the LC and the MS. 

The HP particle beam interface is based on the initial 
development of MAGIC LC/MS (Monodispersed Aerosol 
Generation Interface Combining LC and MS) by Browner 
and others.' 1 Significant design improvements have been 
made in performance, ease of use, and robustness. 

Principle of Operation 

A schematic of the particle beam LC/MS system is shown 
in Fig. 2. A pneumatic nebulizer generates an aerosol from 
the HPLC effluent. As the aerosol passes through a desol- 
vation chamber, the volatile components (such as HPLC 
mobile phase) are vaporized, leaving less volatile compo- 
nents (such as analytes) as submicrometer particles. This 
mixture of vapor and particles enters a two-stage momen- 
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turn separator in which the relatively low-momentum 
vapor molecules are pumped away while the higher- 
momentum particles continue into the source of the mass 
spectrometer, where they are vaporized, ionized, and fi- 
nally mass analyzed. 

The nebulizer, which is pictured in Fig. 3. consists of a 
simple coaxial pneumatic nebulizer. The HPLC effluent 
passes through the fused silica capillary running down the 
center of the nebulizer while the helium nebulization gas 
flows around the capillary and forms the aerosol at the 
exit. The HPLC effluent can be any commonly used HPLC 
mobile phase, such as water, methanol, acetonitrile, 
hexane. or chloroform. The single restriction on the mobile 
phase is that if a mobile phase buffer is necessary, the 
buffer must be volatile. HPLC flow rates between 0.1 and 
1.0 ml/min are acceptable. Typical helium flows are be- 
tween 1 and 2 1/min. The nebulizer has a replaceable 2-fim 
filter to prevent clogging of the fused silica capillary. How- 
ever, since the capillary internal diameter is 100 fim, the 
in-line filter is merely a precaution. 

The desolvation chamber is a hollow cylindrical section 
between the nebulizer and the momentum separator. The 
purpose of the desolvation chamber is to allow sufficient 
time and travel space for effective thermal transfer — via 
the carrier gas — from the desolvation chamber walls to the 
aerosol droplets to evaporate the solvent. The desolvation 
chamber is maintained at approximately 200 torr and 45°C. 
Although earlier attempts in similar interfaces used lower 
pressures at this stage, the relatively high pressure is neces- 
sary for the helium gas to maintain thermal transfer be- 
tween the desolvation chamber wall and the solvent drop- 
lets. The desolvation chamber is thermostatically con- 
trolled to replace the heat that is absorbed as the solvent 
droplets evaporate. 

The momentum separator consists of three main parts: 
a nozzle and two skimmers. The nozzle funnels the flow 
of the vapor particle mixture, creating a supersonic jet ex- 
pansion (and consequently the particle beam), In a super- 
sonic jet expansion, the fluid flow exits from the nozzle at 
supersonic velocity. At a specific distance from the nozzle 
orifice, a region known as the mach disk exists, where the 
flow makes a transition from supersonic, to subsonic veloc- 
ity. The first skimmer orifice is placed just inside the mach 
disk so that the central particle beam is efficiently trans- 

Desolvation Chamber 



LC Effluent 
Inlet 

Capillary 
Helium Inlet 

Fig. 3. Nebulizer detail 



mitted while allowing the vapor molecules to be pumped 
away. Similarly, the second skimmer removes more of the 
vapor while transferring a high proportion of the analyte 
particles. The ultimate result of this two-stage process is a 
pressure reduction from 200 torr in the desolvation 
chamber to approximately 5 torr in the space between the 
nozzle and the first skimmer, then to 0.2 torr in the space 
between the two skimmers, and finally to 2 x 10' 5 torr in 
the mass spectrometer source manifold. 

After exiting the momentum separator, the particle beam 
passes through a transfer tube into the mass spectrometer 
ion source. The particles strike the inner walls of the source 
body (which are held at approximately 250°C) and are va- 
porized. The vapor phase molecules thus generated can be 
ionized by either electron impact or chemical ionization. 

Performance Optimization 

One of the most important features of the particle beam 
LC/MS system is its ease of use. In most cases, optimization 
of performance can be accomplished by a single adjust- 
ment, the nebulizer. It is also possible to adjust several 
other operating parameters, such as desolvation chamber 
temperature, helium flow rate, and source temperature, but 
default values for these parameters usually work well. All 
of these parameters are mobile phase dependent except for 
the MS source temperature, which is compound depen- 
dent. 

A knob on the back of the nebulizer can be turned to 
adjust the axial position of the fused silica capillary in the 
nebulizer body. Since the optimal position is mobile phase 
dependent, the position must be adjusted when running 
different mobile phases. For gradient elulion, a com- 
promise position is chosen. 

Fig. 4 shows the signal intensity for 10-ng injections of 
caffeine as a function of nebulizer position and mobile 
phase. Although the exact shape of this surface will change 
for different fused silica capillary tips, the two-maxima 
shape is typical, the minimum being at a point where the 
fused silica capillary tip is almost flush with the nebulizer 
orifice. Note that when higher proportions of water are 
used in the mobile phase, there is a loss of signal. This 
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Fig. 5. Eltecls on sensitivity of desolvation chamber temper- 
ature and mobile phase composition 

trend is seen with other reversed-phase solvents as well, 
such as water/acetonitrile and water/THF mixtures. If the 
nebulizer is adjusted properly, the loss of signal is approx- 
imately 50%. In the case of normal-phase solvents, such 
as hexane and chloroform, this signal loss is not seen. 

Although the desolvation chamber temperature can have 
a significant effect on sensitivity, it is generally unneces- 
sary to adjust it, since a temperature of 45°C is near optimal 
for most mobile phases. The effects on sensitivity of desol- 
vation chamber temperature and mobile phase composition 
are shown in Fig. 5. Again, higher proportions of water 
show poorer sensitivity than pure organic solvents. In cases 
where high proportions of water are used exclusively (iso- 
cratic), it is sometimes advantageous to raise the desolva- 
tion chamber to 50°C. 

The helium nebulization gas flow rate also has an effect 
on sensitivity for high aqueous mobile phases. In most 
cases, a flow of 2 1/min (approximately 40 psi inlet pressure) 
is optimal, but when using high organic mobile phases, it 
is possible to reduce the flow to 1.5 l/min. The effects on 
sensitivity of mobile phase characteristics and helium flow 
rate are shown in Fig. 6. 

Operation of the particle beam LC/MS system has been 
optimized for liquid inlet flows of 0.5 ml/min or less. Al- 
though flows as high as 1 ml/min can be used, there is a 
loss of sensitivity at higher flows as illustrated in Fig. 7. 
Below approximately 0.5 ml/min, the response plateaus at 
a maximum level. This trend is true for both high aqueous 



and high organic solvents. In practice, the need to use a 
flow rate of approximately 0.5 ml/min or less for maximum 
performance is not a limitation since this is the ideal flow 
range for 2-mm i.d. columns. These columns can be used 
with conventional HPLC equipment as a simple alternative 
to more conventional 4.6-mm i.d, columns while offering 
the additional advantages of reduced solvent consumption 
(approximately fivefold), reduced packing consumption for 
exotic stationary phases, and increased mass sensitivity 
when used with concentration dependent detectors such 
as UV. Columns are commercially available with a wide 
range of selectivities and efficiencies comparable to 4.6-mm 
i.d. columns. 

Finally, the mass spectrometer source temperature plays 
an important role in particle beam LC/MS spectral quality. 
If the source temperature is too high, significant thermal 
degradation may occur. Actually, this effect is similar to 
that seen for all MS operation modes. The effect of temper- 
ature depends upon the thermal stability of the analyte. 
Caffeine, for example, shows very little change in either 
signal intensity or spectral characteristics over a wide tem- 
perature range (150 to 350°C), while some corticosteroids 
show a very strong effect. Typically, signal intensity and 
thermal degradation increase with increasing source tem- 
perature. Thermal degradation is evidenced by a decrease 
in the ratio of higher-mass ions to lower-mass ions. 

Quantitative Performance 

Because of its relatively recent introduction, particle 
beam LC/MS has not been fully characterized. In particular, 
the quantitative performance has been evaluated in depth 
for only a small number of compounds. In addition to 
studies already under way. however, user-generated results 
will quickly help to clarify this area in the near future. 
This section summarizes the performance to date. 

Response factors for particle beam LC/MS are not totally 
uniform. As a result, different compounds exhibit a range 
of detection limits. This is illustrated by the histogram 
shown in Fig. 8. The data in this plot shows the minimum 
detectable quantities (MDQs) for 92 pesticides in nano- 
grams. The tests were run on an HP 5988A mass spectrom- 
eter in flow injection analysis (plug injections) and calcu- 
lated as the amount required to generate a signal to peak-to- 
peak noise ratio (S/N) of 2 using total ion current (TIC) in 
full-scan (scan width of 50 amu to the molecular weight 
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+ 50 amu) data acquisition. It can be seen from this data 
that 50% of the compounds tested show detection limits 
below 25 ng. As a rule of thumb, 100 ng of most compounds 
will generate useful mass spectra. There are compounds 
that perform especially poorly in EI, such as glyphosine 
(MDQ = 635 ng) and compounds that perform especially 
well, such as diuron (MDQ = 2 ng). Although tests for the 
MDQs of these pesticides had not been run on the newer 
HP 5989A mass spectrometer at the time this paper was 
written, the results are expected to improve by about a 
factor of five when using the newer instrument. It should 
be noted that while the response factors do show some 
variation, the range is less than that seen for thermospray 
on similar compounds. 

The linearity of particle beam LC/MS is relatively inde- 
pendent of sample characteristics. Although the calibration 
curve is fit well with a standard linear function (r z = 
0.9995), there appears to be a reproducible deviation from 
linearity at lower levels. This can be seen in Fig. 9, which 
is a calibration curve for caffeine. The data shown is from 
selected ion monitoring for a mass-to-charge ratio (m/z) of 
194. (The molecular weight of caffeine is 194.) 

The reproducibility of particle beam LC/MS is excellent. 
Typically, full-scan EI TIC data shows relative standard 
deviations (RSD) of 10% or less, while extracted ion cur- 
rents or selected ion monitoring data shows RSDs of 5% 
to 7%. depending on the concentration level. This repro- 
ducibility is partially the result of noise characteristics that 
are relatively independent of HPLC flow pulsations, yield- 
ing smooth spike-free chromatograms. 

Applications 

Particle beam LC/MS has potential utility in solving 
varied analytical problems. From the confirmation of iden- 
tity and quantitative analysis of environmental contamin- 
ants to structure elucidation of pharmaceutical and biosci- 
ence related samples, the capability of generating EI or CI 
spectra from previously unapproachable compounds opens 
a number of exciting possibilities. 

One of the application areas of greatest potential for par- 
ticle beam LC/MS is the analysis of samples of environmen- 
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tal interest. Particle beam LC/MS solves two critical prob- 
lems in this area. First, it allows samples to be analyzed 
that cannot be analyzed by GG'MS. In a recent study of a 
California site, 5 it was determined that only 10% of the 
total organic halogen (TOX) could be accounted for using 
conventional analytical methods. This brings up the 
frightening question. "What potential health hazards are 
we exposed to but unable to monitor because of analytical 
limitations?" Particle beam LC/MS may allow us to expand 
the range of compounds that we are able to examine. Sec- 
ond, because of the legal and economic ramifications of 
environmental monitoring, it is critical that the identifica- 
tion of environmental contaminants be unequivocal. In 
many cases, the CI spectra provided by thermospray or 
other LC/MS techniques simply lack sufficient information 
content to make these identifications. The EI spectra pro- 
vided by particle beam LC/MS. on the other hand, are gen- 
erally specific enough to be a source of positive identifica- 
tion. 

In 1987. approximately 150 compounds were removed 
from the U.S.A. Environmental Protection agency's Appen- 
dix VIII to form Appendix IX. for the most part because of 
insufficient analytical methodology. Fig. 10 shows the sep- 
aration of some of those compounds. Note the excellent 
chromatographic resolution and fidelity. Of the com- 
pounds shown, the spectra of all but one (amitrole) were 
found in the Wiley/NBS spectral library and were, in fact, 
the first choice identified by probability-based matching 
(PBM) using a computer-based library search in spite of 
the fact that none of them is amenable to GC/MS separation. 
Many of the spectra found in the Wiley/NBS spectral library 
were generated by direct insertion probe (DIP).* 

A similar environmental application, the analysis of 
triazine pesticides, is shown in Fig. 11. Although some of 
the triazine pesticides can be separated using CC, HPLC is 
the separation method of choice because of its simplicity 

•Direct insertion probe 13 a technique whereby a small amount ot the matonal is analyzed 
by placing il on a heated probe, which .s inserted directly Into the mass spectrometer ion 
source II the material can be vaporized without decomposing, ma6S spectra can be 
obtained 
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and the on-line sample handling characteristics of auto- 
mated HPLC. Using a very simple valving configuration, 
it is possible to preconcentrate relatively large volumes of 
environmental samples automatically. The spectra shown 
on the left in Fig. 11 are extracted from a peak in the total 
ion chromatogram that appears to be a single homogeneous 
peak but is. in fact, two nearly coeluting components. 
Through selected ion profiles, it is possible to separate and 
quantify these two compounds. 

Fig. 12 shows an example of a sample of pharmaceutical 
interest, the separation of corticosteroids. As mentioned 



above, corticosteroids show a strong temperature depen- 
dence. Although signal intensity can be enhanced by using 
a higher source temperature, this results in increased ther- 
mal degradation. The chromatogram shown represents 100 
ng per component at 250°C. 

Another example of a life-science application is the sep- 
aration of aflatoxins Bl, B2. Gl, and G2, as shown in Fig. 
13. Through the use of selected ion monitoring, it is possi- 
ble to delect and confirm the presence of these compounds 
at relatively low levels. 

Finally, the analysis of monosaccharides and disac- 
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Fig. 12. Separation of cortico- 
steroids by particle beam LC/MS. 



charides using ammonia chemical ionization particle beam 
LC/MS is shown in Fig. 14. This application provides a 
means of performing group-type separations since all pen- 
tose monosaccharides, hexose monosaccharides, and 
homogeneous and mixed disaccharides yield group-spe- 
cific spectra. Note that the detection limits are well below 
those obtainable with conventional HPLC and refractive 
index detection. 

Conclusion 

Particle beam LC/MS offers an exciting new approach to 



interfacing LC and MS. Its El capability, excellent quantita- 
tive performance, and ease of use promise to make it the 
new standard for routine LC/MS operation. It should be 
noted that, like any technique, particle beam LC/MS does 
have its limitations, and there are samples that will be 
better approached using other techniques such as thermo- 
spray LC/MS. Furthermore, particle beam LC/MS is a rela- 
tively new technique and is not totally mature. There are 
a number of areas that remain to be understood and charac- 
terized. Hewlett-Packard's goal in implementing particle 
beam LC/MS is to provide a tool for solving analytical prob- 
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lems. As experience accumulates, strengths and limitations 
of the technique will become more clearly defined. 

Afterword 

As this article was going to press, the HP 5989A mass 
spectrometer was introduced, along with a new particle 
beam interface. The data in this article was acquired using 
the older HP 5988A system. Data taken to date on the newer 
HP 5989A system indicates an improvement in sensitivity 
on the order of five to one over the HP 5988A. This improve- 
ment is compound dependent. 
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Advances in IC Testing: The Membrane 
Probe Card 



Conventional integrated circuit wafer test probes have 
mechanical and electrical weaknesses, especially for 
testing high-frequency or high-speed devices and chips 
that have large numbers of inputs and outputs. Membrane 
probe technology overcomes most of these limitations. 

by Farid Matta 



WAFER TEST TERMINOLOGY and practices vary 
between IC manufacturers. However, most test 
procedures fall into one of two general categories: 
parametric testing and die-sort testing. 

Parametric testing is intended to check basic device data 
such as threshold voltages and sheet resistances. It is per- 
formed on special patterns, known as test chips, included 
on the wafers. For a given wafer or wafer lot, passing the 
parametric test is a necessary but not sufficient condition 
for yield. 

Die-sort testing is performed on all individual chips to 
sort out the good from the bad. It is normally designed as 
a sequence of increasingly complex routines so that gross 
failures are detected early and test time is not wasted on 
useless chips. Ideally, die sorting culminates in an at-speed 
test that exercises the chips at a frequency at least as high 
as the intended application. This way, the manufacturer 
ascertains that the parts will perform to specifications be- 
fore more resources are spent on their packaging. 

The hardware involved in either of the above processes 
typically consists of an electronic tester, which executes 
the test program, a prober, which performs the mechanical 
manipulation of the wafers, and a probe card, which pro- 
vides the electromechanical interface between the tester 
and the device under test (DUT). Usually, the probe card 
is connected to the tester via a printed circuit board known 
as the probe-card motherboard or the performance board, 
which is customized for individual ICs or IC families. 

The test software is the multitude of programs that con- 
trol the electronic tester, commanding it to apply to the 
inputs of the DUT specific combinations of voltages and 
currents (known as test vectors), and to measure certain 
voltages, currents, and time intervals at the outputs of the 
chip. The measured responses are then compared with pre- 
determined allowed ranges, and accepted or rejected ac- 
cordingly. 

Testing High-Performance Devices 

Wafer test requirements vary with a number of factors. 
For example, certain specifics are dictated by the technol- 
ogy (bipolar, MOS. GaAs). by functionality (logic, memory, 
linear), by the nature of the signal (digital, analog, mixed- 
signal), and by other factors. In any of these categories, 
there are typically » majority of low-Ui-moderate-perior- 



mance products and a smaller number of high-performance 
ones. The definition of what constitutes a high-perfor- 
mance IC may not always be clear. However, at least for 
wafer testing, two categories of chips pose known chal- 
lenges: devices with high input/output (I/O) counts and ICs 
designed to operate at high frequencies or high switching 
speeds. 

Despite the fact that the probe card is the smallest and 
least expensive component of the test setup, it is usually 
the main cause of the difficulties experienced in testing 
high-performance devices. Specifically, when the number 
of contact pads on the chip is greater than about 150. and/or 
when the contact pads are spaced particularly closely, it 
is difficult or impossible to procure conventional probe 
cards that will work reliably in factory conditions. Also, 
when the operating frequency or switching speed is high, 
the probe card's parasitic effects can distort the test condi- 
tions as well as the measurement results. 

Distortions resulting from probe-card parasitic effects 
can occur when either of the following conditions is pres- 
ent: 

■ The wavelength of the highest significant frequency is 
of the same order as the linear dimensions of the probe. 
When this is true, at any given instant the voltages and 
currents at different points of the probe can be substan- 
tially different. In this case the probe represents a trans- 
mission line section, in which such phenomena as signal 
reflections can become dominant. 

■ Parasitic reactances in the probes are sufficiently high 
to redistribute the circuit voltages and currents. In digital 
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situations the same criterion is formulated differently; 
namely, one is faced with a high-speed testing situation 
when the DUT switches faster than the time constant of 
the circuit containing the parasitic reactance. 
Chip makers sometimes circumvent the difficulty of ob- 
taining high-pin-count probe cards by using self-test, so 
that only a subset of the pads needs to be accessed. How- 
ever, this approach imposes a penalty in wafer "real estate" 
and results in incomplete test coverage. No way to circum- 
vent the signal integrity problem has yet been found. 

Failure to perform at-speed testing at the wafer level 
leads to the wasteful packaging and retesting of a certain 
volume of bad chips that could have been identified and 
rejected earlier. Depending on the complexity of the part 
and on the signal frequencies involved, that fraction can 
be as high as 10% of the total. The financial impact depends 
on the incremental packaging and testing cost. To illustrate 
the magnitude of the problem, consider the following con- 
ditions, which are not unusual for a high-performance IC: 

Annual production volume: 100,000 chips 
Fraction of rejects at packaged test: 10% 
Cost of packaging per chip: $100 
Cost of final test per chip: $2 
Total waste per year: SI ,020,000. 

Hence, the availability of at-speed testing capability at 
the wafer level is of pressing importance to the IC industry, 
and Ihe main element of that objective is the development 
of an IC probe card capable of addressing a large number 
of inputs and outputs and of maintaining signal integrity 
for a wide range of frequencies and operating speeds. To 
develop such a technology, it is necessary to identify and 
formulate the problems preventing conventional probe 
cards from delivering the needed prformance. 

Conventional Probe Card Technology 

A conventional wafer probe card consists of a set of fine 
sty I i , or probes, mounted on a carrier substrate, typically 
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a printed circuit board. The probes are arranged so that 
their tips form a pattern identical to that of the DUT's 
contact pads. The outward ends of the probes are soldered 
to traces on the carrier printed circuit board, which extend 
to a connector that interfaces the probe card with the per- 
formance board. 

The probe card is normally mounted face down on the 
prober, which brings the wafer to be tested to a position 
under the probe card, aligns it so that its contact pads are 
against the tips of the probes, and raises the wafer until 
contact is made. In practical conditions the tips of the 
probes may not be precisely in the same plane, and Ihe 
probe card may not be exactly coplanar with the surface 
of the DUT. To compensate for such variations, the prober 
raises the wafer beyond first contact by a controlled 
amount, called the overdrive. 

The probes on the probe card are usually held at a low 
angle to the plane of the DUT, so that when they are pushed 
by the wafer, the tips slide along the surfaces of Ihe pads. 
This horizontal movement, called scrub, helps remove the 
oxide films on the surface to ensure good electrical contact, 
and is an important element in Ihe art of wafer probing. 

A number of variations on this basic technology exist, 
which attempt to improve Ihe mechanical and electrical 
performance of the probe card. In some advanced versions, 
the carrier printed circuit board is designed lo provide a 
controllcd-impedance environment in which each trace 
presents a section of transmission line of known charac- 
teristic impedance. A schematic illustration of a line on a 
conventional probe card is shown in Fig. la. 

Conventional probe cards have a number of inherent 
limitations. Some are related to their mechanical properties 
and others to their electrical performance. 
Mechanical Limitations. Because the contact element, the 
probe, is a thin long structural member, it tends to change 
its spatial location under the repeated stresses of normal 
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Fig. 2. The conventional probe as a signal line, (a) Equivalent 
circuit, (b) Equivalent low-pass filter 




Fig. 3. The e'/ecl ol parasitic inductance in the time domain 
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operation. Consequently, the user needs to realign the 
probes in the horizontal plane and along the vertical axis 
after some number of touchdowns. This tedious operation 
translates to a significant increase in the cost of ownership. 

At higher probe densities the problem of maintaining 
registration is further aggravated. High densities require 
that the individual probes be made even thinner, longer, 
and closer together. Such conditions are not only more 
conducive to the loss of registration, but they also make 
the realignment procedure too sensitive to be performed by 
the user, and the probe cards need to be returned to the 
factory for costly maintenance. 

Electrical Limitations. The equivalent circuit of a single 
line in a conventional probe card is shown in Fig. lb. Here. 
L p is the inductance of the probe and Z 0 is the characteristic 
impedance of the transmission line formed by the trace 
and the ground plane on the printed circuit board carrier. 
Typical values of these parameters are: L p = 10 nH and 
Z 0 = 50fi. Such a line may be used either to transmit a 
signal from the tester to a DLJT input (or from a DUT output 
to the tester), or to supply a power or a ground connection 
to the DUT. We will discuss its behavior in each of these 
two situations. 

Fig. 2a shows the equivalent circuit of a conventional 
probe card in a simplified input-connection configuration. 
(An output connection would not be much different in 
principle.] In the frequency domain, the parasitic induc- 
tance L,, of the probe causes the circuit to behave like the 
low-pass filter shown in Fig. 2b, and determines the 
bandwidth of that filter. Assuming matched conditions, 
the upper 3-dB limit of the band is the frequency f at which: 

(2irf)(2L p ) = Z„. 

For Z 0 = 50ft and L,, = 10 nH we find the bandwidth to 
be about 400 MHz. 

The effect of the needle inductance in B high-speed 
switching situation is better illustrated in the time domain 
(see Fig. 3). When the tester sends to the DUT a pulse 
stimulus having a rise time t rs . the signal received at the 
input of the DUT will have a longer rise time, t^, because 
of the circuit's parasitic inductance 2L,,. The increase in 
rise time is approximately 2.2 limes the time constant 2L p / 
Z„, or about 1 ns. 
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Fig. 4. A power line in a conventional probe 
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Generally, a circuit s bandwidth BW and its effect on the 
rise time t r are related by the known expression: 1 

BW(3-dB) = K/t r , 

where K is a constant that ranges between 0.35 and 0.45. 
With this in mind, the bandwidth and the rise time can be 
used interchangeably. 

Waveform deterioration is not the only problem caused 
by the parasitic inductances of the probes. In Fig. 2a. the 
ch ip ground node and the tester ground node are not always 
at the same electrical potential. This can lead to erroneous 
testing and/or to unwanted coupling between different sig- 
nal lines served by a common ground probe. Another prob- 
lem is that the discontinuity between the probe and the 
transmission line causes multiple reflections of the signal, 
which result in a long settling time. Also, the mutual induc- 
tance and the coupling capacitance between the long un- 
shielded needles contribute to unacceptable levels of cross 
talk between the signal lines. 

In the case when a line of a conventional probe card is 
used for power delivery, the high inductance of the probe 
can cause significant variations in the voltage levels of both 
the bias line and the associated ground connection. Consid- 
er, for example, the circuit of Fig. 4. in which the power 
line is at a voltage V. If the DUT switches a current 1 in a 
time interval dt, a voltage dV will develop across each of 
the probes, temporarily reducing the voltage across the 
DUT to V - 2dV. This change in the voltage can be roughly 
expressed as: 

dV = Lpl/dt. 

For example, when eight drivers are simultaneously 
switching 10 mA each in 1 ns, and the probe inductance is 
10 nH. the power supply disturbance 2dV will be in excess 
of 1.5V. 

In addition to the just-described phenomenon, the volt- 
age drop developing across the parasitic inductance of I he 
ground connection again causes the chip's ground potential 
to deviate temporarily from that of the tester. The differ- 
ence, known as the ground bounce, is coupled into other 
signal lines as unwanted and unpredictable noise. 
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Requirements for High-Performance Probe Cards 

Based on the analysis of the present probe-card technol- 
ogy and its shortcomings on the one hand, and of the cur- 
rent and future needs of the industry on the other, one can 
formulate the requirements for the more advanced probe 
card that is needed. Since the shortcomings of existing 
probes have been identified as pertaining to the areas of 
contact density and signal fidelity, it is natural to define 
the incremental requirements in the same terms. 

Requirements related to contact density include: 

■ The technology should allow the creation of a large 
number of contact points (more than 500). 

■ The minimum contact pitch, that is, the center-to-center 
distance between the closest contact points, should be 
as low as 0.004 inch. 

■ The contact points should have a fixed alignment in the 
plane parallel to the wafer under test. 

■ The contact points should be able to move with respect 
to each other in the verical direction to accommodate 
normal variations in wafer topography- 
Requirements related to electrical performance include: 

■ The bandwidth of a line should be at least 10 to 20 times 
the clock rate of the targeted digital systems (i.e., 2 to 3 
GHz). 

■ A controlled-impedance. reflectionless electrical envi- 
ronment should extend from the tester to within at most 
1 mm from the I/O pads of the DUT. 

■ The uncompensated inductance of the contact must not 
exceed 0.1 nH. 

■ The cross talk between adjacent lines should be at least 
(wo orders of magnitude less than in a conventional 
probe card of the same density. 

The Membrane Probe Concept 

The membrane probe is a proprietary wafer probing tech- 
nology developed at Hewlett-Packard's Circuit Technology 
R&D Laboratories as a solution to the high-performance 
wafer-level test problems described above. The concept of 
the membrane probe card is depicted in Fig. 5. As shown 
in the illustration, a thin and flexible dielectric film (a 
membrane) supports a set of microstrip transmission lines 
that connect the DUT to the test electronics. Each micro- 
strip transmission line is formed by a conductor trace and 
a common ground plane positioned on the opposite side of 
the flexible membrane. The conductor traces and the 
ground plane are patterned on the membrane using photo- 



lithographic: techniques. 

Given the thickness and the material of the membrane, 
the width of a signal trace is chosen to obtain the desired 
characteristic impedance Z„ of the microstrip transmission 
line. Typical values of Z„ in common use are 50 and 75 
ohms. 

Contact to the DUT is made by an array of microcontacts 
which are plated up at the ends of the transmission lines 
through holes in the insulating membrane. The membrane 
is operated under low tension in a drumhead configuration 
so as to planarize the contact array. The tension in the 
membrane is carefully controlled to allow a degree of inde- 
pendent motion of the contact points in the vertical direc- 
tion, thus accommodating small variations in the heights 
of the contacts or in the topology of the device under test. 

With regard to the need for higher pin counts and contact 
densities, the membrane probe card technology offers a 
quantum jump in comparison with the conventional tech- 
nology. In the membrane probe, the leads and the contact 
points are created by photolitographic means with inhe- 
rently high resolution and positioning accuracy. This al- 
lows the creation of fine, dense patterns, and makes the 
manufacturing process, and ultimately the cost, virtually 
independent of the complexity of the pattern. 

Since the contact points are fixed on a common carrier 
(the membrane), they are fundamentally aligned for life in 
both the vertical direction and in the plane of the DUT. 
This eliminates the need for probe realignment, which is 
an extremely labor-intensive and costly operation in the 
conventional technology. 

In the area of electrical performance, the membrane probe 
technology presents an equally significant advance. The 
transmission-line configuration extends all the way to 
within 0.1 mm of the DUT's I/O pads, thus providing a 
carefully controlled electrical environment in practically 
the entire path of the signal. There is very little uncompen- 
sated lead inductance to cause waveform degradation or 
power or ground potential bounce, or to generate signal 
coupling through a common ground inductance. 

Furthermore, the presence of a ground plane so close to 
the leads concentrates the electric field under the traces, 
which minimizes the coupling capacitance between them, 
thus greatly reducing cross talk. 

Architecture of the Membrane Probe 

The architecture of the membrane probe card is shown 
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in Fig. 6. The membrane, configured as described above, 
is attached to a printed-circuit-board carrier, which also 
carries termination resistors, bypass capacitors, or any 
other necessary components. A force delivery mechanism 
is mounted on the printed circuit board carrier and is de- 
signed to perform three distinct and independent func- 
tions: 

■ Apply a force to the microcontacts sufficient to obtain 
a low and stable contact resistance. 

■ Activate a scrubbing motion to ensure the removal of 
surface insulating layers, including oxides, from the sur- 
face of the DUT. 

» Provide the mechanical degrees of freedom necessary to 
ensure continuous conformance of the plane of the mi- 
crocontacts to the plane of the DUT. 
The required contact force is exerted on the membrane 
by the two leaf springs shown in Fig. 6 through a rigid 
translator ring attached to the membrane. The primary fac- 
tor determining the total force needed is the force per con- 
tact, so the total force depends on the number of contact 
pads in the DUT and is set by a proper choice of leaf spring 
thickness. It was empirically determined that for the selected 
bump material to make a low-resistance contact with 
aluminum (the most widely used pad material in ICs). the 
force per bump must be at least 10 grams. Taking this into 
account along with other considerations, the range was 
determined to be 15 ± 5 grams. 

As mentioned earlier, the scrubbing motion of the contact 
bumps with respect to the probed surface is of critical 
importance to obtaining a low, stable, and repeatable con- 
tact resistance, especially with non-noble materials. For 
aluminum, the minimal acceptable scrub action was found 
to be about 10 micrometers. The upper limit is defined by 
the size of the contact pads on the DUT, and for most 
practical cases is about 25 /xm. In the membrane probe, the 
scrub action is built into the force delivery mechanism 
rather than implemented using external actuators. 

The compliance of the probe's contact points to the sur- 
face of the DUT is perhaps the most critical prerequisite 
for successful probing. The importance of compliance 
stems from the fact that in practical conditions the position 
of the probe card in the prober can never be adjusted accu- 
rately enough to make it perfectly coplanar with the wafer's 
surface. Even if such an adjustment could be made, every 
wafer has a different bow and taper, and therefore presents 



a new surface to the probe. It is impractical to readjust the 
probe for every wafer. 

In the conventional wire probe, compliance is achieved 
"naturally" because the long needles are flexible and there 
is virtually no mechanical linkage between individual con- 
tact points. In the membrane probe, special provisions need 
to be made to achieve adequate surface compliance. These 
provisions must accommodate two modes of deviation 
from coplanarity: a short-range mode and a long-range 
mode. The short-range mode consists mainly of variations 
in the bump height and in the topography of the DUT. The 
long-range mode is a general tilt of the probe's surface with 
respect to the plane of the DUT. The two modes are funda- 
mentally independent of each other. The force delivery 
mechanism of the membrane probe has been designed to 
provide both short-range and long-range compliance with 
the DUT surface at every touchdown through indepen- 
dently acting micromechanical means. 

At the outer edge of the printed circuit board carrier, 
connectors are provided to interface with the tester's per- 
formance board. The size and shape of the probe's printed 
circuit board carrier and the type of interface connector 
are different for different probe/tester combinations, but 
the core remains the same. 

Performance of the Membrane Probe Card 

The performance of the membrane probe card has been 
fully characterized both parametrically and in actual use 
at alpha sites. A parametric evaluation is one that is carried 
out in the laboratory under controlled conditions, and is 
based on special test structures designed for the purpose. 
The products of a parametric evaluation are the basic pa- 
rameters of the tested probe card. They reflect its intrinsic 
qualities, and are independent of the other components 
involved (tester, DUT, etc.). Examples of parametric mea- 
surements are characteristic impedance and bandwidth. 

An alpha-site evaluation is one in which the probe card 
is used to test a real IC in a factory atmosphere in conjunc- 
tion with all the other components of the test setup. Its 
purpose is to verify the probe card's performance and un- 
cover any issues that may occur in realistic conditions. 
Parametric Evaluation. The parametric evaluation of the 
membrane probe card covered both its dc and its ac prop- 
erties. The dc parameters measured were the contact resis- 
tance and the current carrying capacity. The ac parameters 
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were the characteristic impedance, the bandwidth, the 
pulse rise time, and the cross talk between lines. 

Contact resistance was evaluated by measuring the total 
resistance between one of the probe card's lines and an 
aluminized silicon wafer, then subtracting the known trace 
resistance. Aluminum (as a 1-^zm-thick film) was chosen 
for two reasons. First, it is the most widely used IC metal- 
lization, and second, it is the most difficult metal to make 
contact with because of its propensity for oxide formation. 

A plot of the contact resistance to aluminum as a function 
of the number of touchdowns is shown in Fig. 7. As can 
be seen, the contact resistance remains low and fairly con- 
stant for over 20,000 touchdowns. It then starts to deterio- 
rate as oxide debris accumulates on the microcontacts. 
After a simple cleaning, however, the low resistance is 
restored and the behavior is repeated. An important utility 
of this plot is that it defines the cleaning frequency required 
to attain stable performance. Membrane probes were found 
to deliver low and stable contact resistance for up to 1 
million touchdowns when cleaned once every 20,000 cycles. 

Current carrying capability of a trace was defined as the 
dc current that can be continuously passed through that 
trace without an observable change in its appearance. For 
a standard signal line the current carrying capability was 
found to be about 300 mA and was relatively independent 
of trace thickness in the range of 0.5 to 1 oz/ft 2 . Coinciden- 
tal ly, roughly the same current carrying capability was mea- 
sured for the contact between the bump and the wafer's 
aluminum metallization. However, in this case it was de- 
fined as the maximum dc current at which no hysteresis 
is observed in the VI characteristic curve. 

Characteristic impedance measurements were made 
using time-domain reflectometry (TDR). 2 The TDR profile 
of a signal line is shown in Fig. 8. Parts of the plot corres- 
ponding to various sections of the circuit are marked: a 
5012 controlled-impedance connector, the trace on the 
probe card's printed circuit board carrier, and the micro- 
strip line on the membrane. According to this TDR signa- 
ture, taken with a 50-ps system, the characteristic imped- 
ance of the line tested is within ±10% of the target value 

of son. 

Transmission response to a 50-ps step function excitat ion 




Time (200 ps div) 



Fig. 8. Time-domain reflectometry profile and characteristic 
impedance. 



was recorded for the same 50ft signal line and is shown 
in Fig. 9. The 10-to-90% rise time of the response was 
determined to be about 180 ps, a considerable fraction of 
which occurs in the 80-to-90% region. 

Bandwidth measurements were made by plotting the fre- 
quency response curve of one of the membrane probe card's 
lines. This curve, also known as a Bode plot, is shown in 
Fig. 10. The 3-dB bandwidth of the tested line was found 
to be in the range of 2.5 to 3.0 GHz. 

Cross talk between the probe card's lines was measured 
as a function of frequency, and the results are plotted in 
Fig. 1 1 . The measurements were made on a card containing 
272 traces, which gives an idea of the spatial density of 
the lines in this case. One of the two curves shown is for 
adjacent lines, while the other curve is for alternate lines. 
At 100 MHz the cross talk is —45 dB for adjacent lines and 
-78 dB for alternate lines. In comparison, a conventional 
wire probe card showed adjacent-line cross talk of - 38 (IB 
at a density less than one third that of the membrane probe 
card of Fig. 11. 

Alpha-Site Testing. A number of membrane probe cards 
were fabricated to test specific chips of various technol- 
ogies, I/O counts, pad metallurgies, and functionality. The 
testing of these chips was conducted in HP's wafer fabrica- 
tion plants. Below is a brief description of the tests and 
their results. 

L Bipolar ECL Flash Analog-to-Digital Converter. This 1.5- 
watt, mixed-signal chip with 50 I/O pads and gold metalli- 
zation was tested at a 10-MHz sampling rate using a 
tungsten wire probe card. It was then retested with the 
membrane probe card, and the test results were compared. 
The superior accuracy of the membrane probe card is dem- 
onstrated by Fig. 12. In this plot, the voltage at test point 
1, denoted here as V lpl , is recorded for a sample of 120 
dice. This voltage is offset from the chip ground by the 
drop across a forward-biased junction, and its measurement 
is intended to detect variations in the chip's ground poten- 
tial. The results show a progressive deterioration in the 
stability of the measurements made with the wire probe 
card, while the membrane probe card measurements are 
consistent over the entire test. 
The accuracy of the membrane probe data was confirmed 
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Fig. 9. Transmission response and rise time. 
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Fig. 10. Bode plot and the 3-dB bandwidth. 

by packaging a number of dice and repealing the measure- 
ments on the packaged parts. The spread of the membrane 
probe card measurements translates to a contact resistance 
stability of better than 5 mfi, which is 40 times better than 
that of the wire probe card. 

The membrane probe's abiJity to make repeated touch- 
downs on the same die without appreciable damage to the 
pads is illustrated by Fig. 13. For 200 touchdowns the total 
variation is less than 1.2 mV. which corresponds to a con- 
tact resistance variation of 6 mft. By contrast, using a wire 
probe for more than two touchdowns on the same chip 
usually causes enough damage to render the pads unbond- 
able. This capability is of significant value to chip manufac- 
turers, who sometimes lose up to 5% of their chips to pad 
and passivation damage. 

2. Bipolar ECL Digital-to-Analog Converter. This rep- 
resented an at-speed analog test of an industry standard 
product using the HP 9840 VHF linear tester and the mem- 
brane probe card shown in Fig. 14. The analog output re- 
sponse of the device at a 10-MHz clock rate is presented 
in Fig. 15 for both the membrane probe card and a conven- 
tional counterpart. The rise and fall times are about the 
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same at 1.3 and 1.0 ns respectively (they are essentially 
determined by the switching characteristics of the device 
rather than by the probe's performance). However, the set- 
tling time measured by the membrane probe card is only 
9 ns compared with 32 ns for the conventional probe card. 
This significant difference is a result of the improved im- 
pedance matching in the membrane probe card. 

3. NMOS CPU. A membrane probe card was used to test a 
32-bit microprocessor at 85°C (Fig. 16). The 8.4-mm-square. 
15-watt chip has 272 peripheral aluminum pads arranged 
in two staggered rows at an effective pitch of 1 10 jtm. This 
type of device has very- large current transients, and the 
stability of power buses is of special concern. 

The device was normally tested at speed only after pack- 
aging. With the membrane probe card, it became possible 
to run the at-speed package test on the wafer for the first 
time. Careful membrane layout and close positioning of 
over 130 bypass and termination components helped ob- 
tain the desired performance. 

4. CMOS ASIC. In this alpha-site test, a membrane probe 
card was used to test high-pin-count ASICs (application- 
specific ICs) before TAB (tape automated bonding) inner- 
lead bonding. The probe card addressed 180 gold mesa 
bumps, each 75 fim square, placed on a 150-/xm pitch. 

One part of the lest was designed to evaluate the mem- 
brane probe card's fitness for the specific purpose of prob- 
ing bumped wafers. In that part, 600 passes were made on 
one wafer, which had about 100 dice. The average contact 
resistance variation was found to be less than 1 3 milliohms. 
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Fig. 12. Measurement accuracy. 
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Fig. 13. Measurement repeatability. 

and no significant damage to the gold bumps on the wafer 
was observed. Attempts to repeat the same test with a con- 
ventional wire probe card failed after only about 5000 
touchdowns. The gold bumps on the wafer were severely 
damaged, especially at the edges, and the probe needles 
went so badly out of alignment that on-site repair was no 
longer feasible. 




Fig. 14. The membrane probe for DAC testing 

One benefit of using the membrane probe card to test 
bumped wafers is the probe's ability to detect individual 
short bumps, a commonly encountered defect. Such 
bumps, if undetected, would cause assembly rejects at the 
subsequent inner-lead bonding step. 

Conclusions 

An advanced wafer probing technology, the membrane 
probe card, has been developed in response to an increas- 
ingly acute problem in the IC industry. The technology 
allows at-speed testing of high-performance integrated cir- 
cuits at the wafer level, and significantly extends the limits 
of pin count and density that can be accessed by the IC 
test engineer. The new probe card has been fully evaluated, 
parametrically as well as in a number of alpha sites. 
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Fig. 16. The membrane probe lor microprocessor testing- 
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